技术选型的决策原则（够用 vs 主流 vs 前沿）

一句话速记

技术选型不是选”最好的技术”，是选在当前约束下代价最小的技术。三个维度：① 团队能力——团队能不能 hold 住？搞不定的技术 = 安全漏洞 + 线上事故 + 招不到人；② 生态成熟度——有没有人在生产上跑过（不只看 star，看生产踩坑文章的数量）；③ 演进成本——选了这个 2 年后如果要换，代价多大？默认选择：够用 > 主流 > 前沿。 前沿只在”现有技术真的做不到”时才选，不是”可能更优雅”。

通俗解释（5 分钟版）

选型陷阱：

"Rust 比 Java 快多了，我们下一个服务用 Rust 写吧。"
→ 团队 5 个人，只有 1 个人学过 Rust。
→ 3 个月后那个人离职了。剩下 4 个人看着 Rust 代码发呆。
→ 线上出 bug 没人敢动，只能重写成 Java。
→ 浪费了半年。

正确的选型思路：
"我们的核心瓶颈是 IO 等待，不是 CPU。换成 Rust 不会更快。
  如果我们要解决的是内存安全的问题，Rust 有意义。
  但目前的关键瓶颈是团队只有 1 个人会 Rust——这比任何
  技术缺点都致命。"

关键细节

选型三维矩阵

维度 1：团队能力（权重 40%）

问自己：
  1. 团队里现在有多少人能写这个技术？（不是"想学"，是真的写过）
  2. 如果一个人休长假或离职，其他人能不能顶上？
  3. 招到会这个技术的人，市场上候选人池子有多大？
  
规则：
  少于 2 个人能写 = 不选。 "这个很简单，大家一周就能学会"
  是谎言——一周能学会写 demo，半年才能学会写不出事故的代码。

维度 2：生态成熟度（权重 35%）

判断标准（不是 GitHub star 数）：
  1. 有没有>= 3 家众所周知的公司在生产上正式使用？
     （不是"某某大厂在试"，是"正式跑了半年以上"）
  2. 搜 "[技术名] 生产 踩坑" → 出来的结果是"分享经验"还是"求救帖"？
  3. 最新版本发布多久了？（< 1 个月 = 太新；> 2 年没发布 = 可能死了）
  4. Stack Overflow 上的问题有没有靠谱回答？（没人回答 = 出问题只能读源码）

规则：
  没有已知生产案例的不选。你就是那个踩坑的人，
  但你团队和用户不应该为你的探索欲买单。

维度 3：演进成本（权重 25%）

问自己：
  1. 如果 2 年后我们需要换掉它，代价是多大？
     → 数据库：极大（迁移数据代价）；中间件：中等（改配置/接口）
     → 内部工具库：小（改一行 import）
     代价越大的选型越要保守
  2. 它的"锁定效应"多大？
     → 和云厂商绑定？和特定语言绑定？和某个人的知识绑定？
  3. 有没有一个"标准替代品"？
     → 如果你选了一个非标方案，至少要知道"标准方案是什么"、
        你偏离标准的原因是什么

默认选择优先级

第一选择：团队已经会的 + 已经被验证的

例子：团队核心用 Java + Spring Boot。
  新服务默认 Java + Spring Boot，除非有明确理由不用。
  "和以前一样"是最好的选型结果。

第二选择：增加了一个新工具，但团队能消化

例子：团队需要消息队列，没人用过。
  选 Kafka（市场最主流 + 文档最丰富 + 招聘最容易），
  不选某个小众 MQ——即使它在纸面上更快。

第三选择（极少）：前沿技术
  条件：
    ① 现有技术真的做不到这个需求（不是"不够优雅"）
    ② 至少 2 个核心成员愿意 deep dive 且能 hold 住
    ③ 有明确的"如果失败，退回主流方案"的 Plan B 和时间点

常见的选型陷阱

✗ "某大厂用的就是它，我们也应该用"
  → 大厂有 30 个人的基础设施团队去维护。你有吗？

✗ "它的 benchmark 比 XXX 快 3 倍"
  → benchmark 不可信。就算可信，你的瓶颈是不是真的在那？

✗ "它是最新的，社区很活跃"
  → 最新 = 生产验证最少。活跃 = 明天可能 breaking change。

✗ "我是为了团队的成长，让大家学点新东西"
  → 成长的方式有很多——学原理比学工具值钱。学一个工具不是成长。
     用生产系统来练手，是对用户的不负责。

延伸追问

• Q：如果团队里没人会任何消息队列，但我们必须选一个，怎么选？ → 选市场最主流的（Kafka）。有人生产过 = 有人踩过坑写了博客 = 你搜得到。选小众意味着你遇到问题搜不到答案，只能去社区等回复。
• Q：什么情况下可以选前沿技术？ → 两个条件同时满足：① 现有主流方案的硬限制被证实（不是你怀疑、是你在生产上测过）；② 你有足够深的团队（至少 2 个高级工程师能把这个技术吃透 + 愿意 oncall 时处理它的 bug）。满足这两条就可以了——但大多数时候你没满足第 ① 条。
• Q：选了以后发现选错了，什么时候该止损？ → 三个信号：① 它已经出过一次因它的设计缺陷导致的生产事故；② 团队多次因为它的学习曲线而延迟交付；③ 维护它的人力成本持续超过它带来的收益。如果三个信号齐了，止损。不要因为”已经投入了很多”而继续投入更多。

我的记法

• 选型三问：团队能写吗？生产上有人用过吗？2 年后换掉代价多大？
• 默认选项：够用 > 主流 > 前沿。前沿只在”现有做不到”时用
• 最大陷阱：为团队”成长”而选新技术——生产不是训练场
• 一句话：「选技术不是选最好的技术，是在约束下选代价最小的技术——最大的约束永远是团队能力」

状态

• 已背速记
• 能讲通俗版
• 能答追问