# 技术选型方法论

::: tip 前言
**React 还是 Vue？MySQL 还是 PostgreSQL？** 技术选型是每个项目开始时最重要的决策之一。选错了，可能要花几个月重写；选对了，团队效率翻倍。

本章带你建立系统化的技术选型思维，不再凭感觉选技术。
:::

**这篇文章会带你学什么？**

| 章节 | 内容 | 核心概念 |
|-----|------|---------|
| **第 1 章** | 技术雷达 | 了解技术的成熟度 |
| **第 2 章** | 选型维度 | 从哪些角度评估技术 |
| **第 3 章** | 决策矩阵 | 量化对比做决策 |
| **第 4 章** | 常见陷阱 | 避免选型中的坑 |

学完本章，你将掌握一套系统化的技术选型方法，能为项目做出理性的技术决策。

---

## 0. 全景图：技术选型的本质

技术选型不是"哪个技术最好"的问题，而是"哪个技术最适合当前场景"的问题。就像选交通工具——飞机最快，但去隔壁小区不需要坐飞机。

::: tip 选型的核心原则
- **没有银弹**：没有一种技术适合所有场景
- **场景驱动**：先明确需求，再选技术
- **团队优先**：团队熟悉的技术往往是最好的选择
- **可逆性**：优先选择容易替换的方案
:::

通过下面的交互组件，了解当前技术生态的全景：

<TechRadarDemo />

---

## 1. 选型维度

### 1.1 核心评估维度

| 维度 | 关注点 | 权重建议 |
|------|--------|---------|
| **团队能力** | 团队是否熟悉？学习成本多高？ | 高 |
| **社区生态** | 文档质量、第三方库、Stack Overflow 答案数 | 高 |
| **性能需求** | 是否满足性能要求？ | 中-高 |
| **维护状态** | 是否活跃维护？最近一次发布是什么时候？ | 中 |
| **许可证** | 是否与项目的商业模式兼容？ | 中 |
| **招聘市场** | 能否招到熟悉这个技术的人？ | 中 |

### 1.2 实际案例：前端框架选型

```
项目：企业内部管理系统
团队：5 人，3 人熟悉 Vue，1 人熟悉 React，1 人新手
需求：表单密集、权限复杂、不需要 SEO

分析：
- 团队 60% 熟悉 Vue → Vue 优先
- 表单密集 → Element Plus 生态成熟
- 不需要 SSR → 不需要 Next.js/Nuxt
- 结论：Vue 3 + Element Plus
```

---

## 2. 决策矩阵

当多个选项难以直觉判断时，用决策矩阵量化对比。

通过下面的交互组件，体验决策矩阵的使用方法：

<DecisionMatrixDemo />

### 2.1 如何使用决策矩阵

1. **列出候选方案**：比如 React vs Vue vs Svelte
2. **确定评估维度**：团队能力、生态、性能、学习曲线
3. **分配权重**：根据项目需求，给每个维度打权重（总和 100%）
4. **逐项打分**：每个方案在每个维度上打 1-5 分
5. **加权求和**：得出最终得分

### 2.2 示例

| 维度 | 权重 | React | Vue | Svelte |
|------|------|-------|-----|--------|
| 团队能力 | 30% | 3 | 5 | 1 |
| 社区生态 | 25% | 5 | 4 | 2 |
| 学习曲线 | 20% | 3 | 4 | 5 |
| 性能 | 15% | 4 | 4 | 5 |
| 招聘市场 | 10% | 5 | 4 | 2 |
| **加权总分** | | **3.75** | **4.35** | **2.75** |

---

## 3. 常见陷阱

### 3.1 简历驱动开发

> "用这个新技术，我简历上又能多写一条"

选技术应该基于项目需求，而不是个人简历。新技术意味着更多的未知风险和更少的社区支持。

### 3.2 盲目追新

| 心态 | 现实 |
|------|------|
| "新的一定比旧的好" | 新技术可能有未发现的 Bug |
| "大厂在用，我们也该用" | 大厂的场景和你的可能完全不同 |
| "这个技术 Star 数最多" | Star 数不等于适合你的项目 |

### 3.3 忽视迁移成本

选型时不仅要看"用起来怎么样"，还要看"如果要换，代价多大"。优先选择：
- 遵循标准协议的方案（如 SQL vs 私有查询语言）
- 有清晰迁移路径的方案
- 不会深度锁定的方案

---

## 4. AI 助力：用大模型辅助技术选型

大模型可以帮你快速调研技术方案、对比优劣、生成决策报告。

### 4.1 技术方案对比

> **提示词**：
> ```
> 我需要为一个电商项目选择数据库，候选方案：
> MySQL、PostgreSQL、MongoDB。
> 项目特点：读多写少、需要复杂查询、数据量预计千万级。
>
> 请从以下维度对比三个方案：
> 性能、生态、学习曲线、运维成本、扩展性。
> 用表格形式呈现，并给出最终推荐和理由。
> ```

### 4.2 生成架构决策记录（ADR）

> **提示词**：
> ```
> 帮我写一份架构决策记录（ADR），格式如下：
> - 标题：选择 Vue 3 作为前端框架
> - 背景：[项目背景和需求]
> - 候选方案：React, Vue 3, Svelte
> - 决策：Vue 3
> - 理由：[基于团队能力、生态、性能等维度]
> - 后果：[选择后的影响和风险]
> ```

### 4.3 调研新技术

> **提示词**：
> ```
> 我在考虑是否在项目中引入 Bun 替代 Node.js，请帮我分析：
> 1. Bun 相比 Node.js 的核心优势和劣势
> 2. 当前生态成熟度（npm 兼容性、主流框架支持）
> 3. 生产环境使用的风险点
> 4. 适合和不适合使用 Bun 的场景
> 给出客观评估，不要只说优点。
> ```

::: tip AI 使用建议
AI 的知识有时效性——它可能不了解最新版本的变化。对于快速迭代的技术，用 AI 做初步调研后，务必查阅官方文档确认最新信息。
:::

---

## 5. 总结

1. **技术雷达**：了解技术的成熟度，区分采纳/试验/评估/暂缓
2. **选型维度**：团队能力 > 社区生态 > 性能需求 > 维护状态
3. **决策矩阵**：量化对比，减少主观偏见
4. **避免陷阱**：不追新、不跟风、考虑迁移成本

::: tip 终极思考
最好的技术选型往往是**最无聊的选型**。选择成熟、稳定、团队熟悉的技术，把创新的精力留给业务本身。记住：**技术是手段，不是目的。用户不关心你用了什么框架，他们只关心产品好不好用。**
:::

---

## 延伸阅读

- **ThoughtWorks 技术雷达**：每半年发布一次，是了解技术趋势的权威参考。
- **实践建议**：下次选型时，试着用决策矩阵做一次量化对比。
- **架构决策记录（ADR）**：用文档记录每次技术选型的理由和权衡。
- **反面教材**：了解一些因技术选型失误导致项目失败的案例。