04 · 技术选型：框架与中间件的通用决策框架
选型失败很少因为"选错了工具"，更多因为"没先定义需求就选"。 本篇给一套不依赖具体技术的五步决策框架：需求 → 候选 → 评估 → 试点 → 决策。选框架、选中间件、选 AI 模型都用得上。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 用"需求 → 候选 → 评估 → 试点 → 决策"五步闭环，把选型从"拍脑袋"变成"可辩护的决策" |
| 核心内容 | 为什么选型会失败、五步闭环、评估维度与权重、POC 的纪律、决策记录、常见陷阱 |
| 读完能回答 | 选型第一步该做什么？怎么对比两个候选？POC 要测到什么程度才够？ |
| 相关板块 | C01 · 运行时选型 ｜ A01 · 跨端方案对比 ｜ F03 · 技术方案写作 |
一、选型为什么总失败
最常见的三种失败，都不是"技术不行"：
| 失败模式 | 表现 | 根因 |
|---|---|---|
| 需求没定义 | "我们想要个数据库" → 选完发现场景不匹配 | 没先定义约束与量级 |
| 只比功能不比代价 | 全看 feature 列表，不看学习成本/运维成本/生态 | 没有代价意识 |
| 用别人的结论当理由 | "网上都说 XX 好" → 团队没人会用 | 没评估团队能力 |
核心认知：选型是决策，不是考证。它的产出是一份"为什么选它、代价是什么、什么情况下要重选"的记录，而不是一个名字。
二、五步决策闭环
text
① 定义需求 → ② 收集候选 → ③ 评估打分 → ④ 试点验证 → ⑤ 记录决策① 定义需求：先写"约束"再写"功能"
需求分两类，权重不同：
| 类型 | 例子 | 权重倾向 |
|---|---|---|
| 硬约束 | 团队语言、部署环境、许可证、合规 | 一票否决 |
| 功能需求 | 性能、可扩展、生态、易用 | 打分比较 |
硬约束先筛掉一批，剩下才进入对比。没有硬约束的选型，容易变成无限比较。
② 收集候选：控制在 2~4 个
候选太多会瘫痪，太少没对比。规则：主流候选 1~2 个 + 一个"反方"候选（明确知道不适合但拿来对比），用来检验"是不是因为不了解才没选它"。
③ 评估打分：统一维度 + 权重
维度要包含使用代价，不只是功能：
| 维度 | 说明 | 权重示例 |
|---|---|---|
| 团队熟悉度 | 会不会用、上手成本 | 30% |
| 生态与社区 | 踩坑有人帮、招聘容易 | 20% |
| 功能匹配度 | 覆盖需求的比例 | 20% |
| 运维与成本 | 部署复杂度、资源成本 | 20% |
| 长期演进 | 是否在活跃维护 | 10% |
权重按项目定，不是固定值。个人全栈项目权重偏向"上手快 + 运维轻"；团队项目权重偏向"生态 + 招聘"。
④ 试点验证（POC）：用最小可运行验证关键假设
POC 要回答的是"最不确定的那个假设"，不是把功能全部做一遍：
| 要验证的假设 | POC 做法 |
|---|---|
| 性能够不够 | 用真实量级数据压一把 |
| 生态支不支持 | 装好常用插件跑通主链路 |
| 团队能不能上手 | 让核心成员写一个小模块 |
POC 失败不是坏事，它证明了"某候选不匹配"，这正是选型要的答案。
⑤ 记录决策：写成可追溯的记录
把"候选、打分、POC 结果、决策、代价、重选触发条件"写进决策记录（ADR，Architecture Decision Record）。它让三个月后的自己知道"当时为什么这么选"。
三、选型常见陷阱
| 陷阱 | 对策 |
|---|---|
| "最新的就是最好的" | 看维护历史和稳定性，不看发布新闻 |
| "功能最多的就是最好的" | 用到的功能才叫功能，用不到的是学习成本 |
| "只看性能排行" | 性能是场景相关的，用你的数据量压测 |
| "选型是一次性决定" | 设"重选触发条件"（如量级翻倍、团队扩编） |
| "被别人的成功案例说服" | 问清楚人家的量级、团队、约束是否和你一样 |
四、和 F03 的关系
选型结论是方案文档第四段（方案对比）的输入。流程上：F04 定出"选什么"，F03 把"为什么选它 + 代价 + 风险"写进可评审的方案。两篇文章配合，才是一份完整的决策链。
自检清单
- [ ] 先写硬约束再写功能需求，硬约束能一票否决
- [ ] 候选控制在 2~4 个，且含一个"反方"候选
- [ ] 评估维度包含"使用代价"（熟悉度/运维/成本），且有权重
- [ ] POC 只验证最不确定的假设，用真实量级数据
- [ ] 决策记录包含候选、打分、代价、重选触发条件
- [ ] 能说清本项目的"重选触发条件"
常见误区
| 误区 | 事实 |
|---|---|
| "选型 = 对比 feature 列表" | 核心是硬约束 + 使用代价，不是功能数量 |
| "网上测评够用了" | 测评脱离你的场景与团队，只能当候选线索 |
| "POC 把功能全做一遍" | POC 只验证最不确定的假设，做完等于开工了 |
| "选定了就不能改" | 设重选触发条件，量级/团队变了就该重评 |
动手练习
练习 A：做一次真实选型
选一个最近遇到的"要选个工具"的场景（如消息队列、缓存、ORM），走完五步，产出决策记录。
练习 B：写重选触发条件
给上一步的决策写三条"什么情况下要重选"，并说明每个条件的观察信号。
练习 C：审别人的选型
找一篇网上的选型对比文章，用本框架挑刺：它有没有硬约束？有没有代价维度？有没有 POC？结论能不能迁移到你的场景？
相关文档
本区
- 03 · 技术方案写作 —— 选型结论写入方案第四段
- 01 · 工程方法论全景 —— 闭环定位
其他域
- C01 · 运行时选型 —— 后端语言/框架的具体决策
- A01 · 跨端方案横向对比 —— 前端跨端选型实例
- DB07 · NoSQL 选型 —— 数据库选型的决策树实例