做了几年 tech lead，最让我纠结的不是写代码，而是技术选型。记录一下我的决策框架。

为什么技术选型很难

表面原因：选项太多，各有优缺点
深层原因：评估维度不统一，隐性约束没有被挑明

比如：
PM 说：快点，下周要上线
老板说：用成熟技术，别出问题
团队：能不能用我最近在学的那个新框架？
你：...

决策矩阵

我习惯用一个 5 维度矩阵来评估：

1. 团队熟悉度（Team Familiarity）
   已有经验？学习曲线多长？

2. 成熟度（Maturity）
   社区规模？Issue 响应速度？公司是否在维护？

3. 适配度（Fit）
   解决的问题和我们的问题有多匹配？

4. 迁移成本（Migration Cost）
   如果未来要换，代价多大？（锁定风险）

5. 运维成本（Operational Cost）
   上线后维护有多复杂？

实际打分例子（为新项目选状态管理）：

	Zustand	Jotai	Redux Toolkit	Valtio
团队熟悉度	3	1	4	1
成熟度	4	3	5	3
适配度	5	4	3	4
迁移成本	5	4	3	4
运维成本	5	4	3	4
总分	22	16	18	16

最终选 Zustand：适配度最高，团队有基础，迁移容易。

几个常见的反模式

"这个库 GitHub Star 最多"

Star 数量不代表适合你的场景。moment.js 有 4 万 star，但它太重了，现在大家用 dayjs 或原生 Temporal。

"这是大公司在用的"

大公司的场景不等于你的场景。他们有 1000 个工程师维护这个方案，你们有 5 个。

"新技术更先进"

最新 ≠ 最好。问题是：它解决了你现在面临的哪个具体问题？

"先试一下再说"

"试一下"往往变成了"就这样了"。POC 需要明确评估标准，否则很容易沉没成本陷阱。

RFC 文档

我们团队现在重要的技术决策都要写 RFC（Request for Comments）：

# RFC：状态管理方案选型

## 背景

当前项目...存在以下问题...

## 目标

- 统一状态管理方式
- 降低样板代码
- 提升 TypeScript 体验

## 候选方案

### 方案 A：Zustand

优点：...
缺点：...
风险：...

### 方案 B：Redux Toolkit

...

## 建议方案

方案 A（Zustand），原因：...

## 决策标准

如果 [条件]，我们会重新评估。

## 影响范围

- 需要迁移的文件：...
- 预计工时：...

## 反对意见

@张工 认为...，回应是...

RFC 的价值不只是文档，而是：

1. 强迫你想清楚
2. 让团队有发声机会
3. 几个月后可以查为什么做了这个决定

不可逆决策 vs 可逆决策

贝佐斯的"单向门 vs 双向门"理论适用于技术决策：

高可逆性（双向门）→ 快速决策，试了不行就换
  - 状态管理库
  - UI 组件库
  - 测试框架

低可逆性（单向门）→ 慎重决策，多花时间论证
  - 数据库选型
  - 前后端架构（SPA vs SSR vs MPA）
  - 主编程语言/框架
  - 云服务商选择

对"双向门"决策不要过度分析，做决定，跑起来再说。

小结

• 技术选型用多维度矩阵，而不是"感觉最好"
• 重要决策写 RFC，让团队参与，留下决策记录
• 区分可逆和不可逆决策，不可逆的要更慎重
• 避免：以 Star 数、大公司背书、新技术光环作为主要决策依据
• 最重要的问题：这个技术解决了我们现在面临的哪个具体问题？