先把话说清楚：选型没有最优解
网上大量选型文章是「A vs B 优缺点清单」，看完了还是不知道选什么。原因是脱离业务约束的优缺点没有意义：MySQL 的「缺点」在没有写库压力的场景里根本不是缺点。
我的经验是三步走：翻译约束 → 提出可证伪的假设 → POC 验证。选型不是打分题，是假设检验题。
第一步：把业务约束翻译成选型标准
在打开任何技术对比之前，先回答这几个问题，并把答案写成可衡量的指标：
- 规模约束：真实峰值 QPS 预估多少？数据量三年后多大？（拍脑袋要乘 2）
- 一致性约束：业务允许最终一致吗？钱、订单这类不允许。
- 成本约束：预算多少？包括人力成本——一个团队没接触过的技术栈，学习成本常常是隐性的最大成本。
- 运维约束：团队有几个人能值班？能不能接受 3 点起来修一个没人会的组件？
- 演进约束：这个选择锁定了什么？迁移成本多高？
踩坑记录：我早期做过一次「技术理想主义」的选型，给一个日活几千的产品上了当时最时髦的微服务 + 全套中间件，理由是「架构要先进」。结果是 5 个人的团队一半精力花在维护基础设施上。规模不到，先进架构就是负债。架构复杂度和业务复杂度不匹配，是反模式的第一条。
第二步：候选方案，收敛到 2–3 个
把约束翻译成「一票否决项」和「加分项」：
- 一票否决：比如公司合规要求数据不出域 → 纯 SaaS 方案直接出局；团队没人会且招不到 → 冷门语言组件出局。
- 加分项：性能、生态、文档、招人容易度、与现有技术栈的一致性。
先砍掉被一票否决的，剩下 2–3 个做 POC。不要 POC 太多方案，每多一个，验证成本翻倍。
第三步：POC 只验证「那个不确定的假设」
POC 最大的误区是把官方 demo 跑一遍就叫验证。POC 要验证的是你最不确定、错了代价最大的一件事：
- 选缓存：不确定的是「热点场景下命中率与穿透表现」→ 用真实流量回放压测。
- 选消息队列：不确定的是「极端堆积下的吞吐与延迟」→ 造 10 倍峰值流量看积压。
- 选向量库：不确定的是「召回质量」→ 用你自己业务的数据集测，而不是官方 toy dataset。
POC 必须提前写清楚通过标准。我见过太多 POC 跑了两周，结论却是「感觉还行」——没有通过标准，等于没验证。
踩坑记录：有一次选型做 POC，测出来延迟达标但成本超预算 3 倍，因为只测了性能没测成本。POC 的验收维度必须包含性能、成本、运维复杂度三项，只看一项等于盲人摸象。
第四步：把决策写下来（ADR）
选定之后，花 20 分钟写一份架构决策记录（ADR），包含：背景、候选方案、为什么选它、放弃了什么、如果数据变化什么条件下要推翻重选。
ADR 的价值在三个月后：新同学问「为什么不用 X？」时，你不用靠回忆解释，团队也不会反复争论同一个已经决策过的问题。
常见取舍速查（我自己的判断框架）
| 场景 | 我的倾向 | 为什么 |
|---|---|---|
| 数据量百万级以内 | PostgreSQL 单库 | 事务、运维、招人都省心 |
| 只有 1–2 个服务 | 单体 + 进程内缓存 | 微服务是手段不是目的 |
| 读多写少、热点明显 | 加缓存，先不加读写分离 | 少一个数据源就少一种一致性噩梦 |
| 消息量小、要求不高 | 先上简单 MQ 或 DB 队列 | 别为「未来可能」预支复杂度 |
| 需要私有化 AI | 先算 token 成本账，再谈模型 | 见 AI 工程教程系列 |
落地清单
- 写出 5 条以上业务约束，并能量化为指标
- 明确一票否决项，收敛候选到 2–3 个
- POC 只验证 1 个核心假设，且含性能 / 成本 / 运维三维度
- 提前写清 POC 通过标准
- 决策后 20 分钟内写 ADR