PoC 跑通了就上线？技术选型的"充分论证"到底要做到什么程度

背景

我带团队 10 年，技术选型是绕不开的事。一个很常见的流程是：有人提议换某个框架/中间件 → 花两三天写个 demo → 跑通了 → 排期上线。这个流程本身没毛病，但"跑通"两个字，在我这儿从来不算充分论证。

常见分歧

我见过至少三种立场：

立场 A：PoC 够了。 "我们不是做科研，业务先跑起来，边跑边调。" 代表是业务侧 PM 和部分后端同学。逻辑是：选型成本 > 试错成本，先上再优化。

立场 B：PoC + 压测 + 故障注入。 至少要在接近生产的数据量下跑一遍，再模拟几个典型故障（节点宕机、网络分区、依赖超时），确认行为可接受。这是我目前推的标准。

立场 C：必须出 ADR + 对比矩阵 + 回滚方案。 有些大厂/金融团队的硬要求。我理解合规场景下合理，但在 20 人团队里执行成本很高。

我的倾向与理由

我选 B，并且会把"PoC 通过"拆成 5 个可勾选的 gate：

1. 功能正确性——核心路径全过，边界 case 至少覆盖 3 个；
2. 容量——在目标 QPS × 3 的负载下 P99 达标（不是 P50，P50 谁都能跑）；
3. 故障——kill 一个节点 / 模拟网络分区，确认不丢数据、不脑裂、不雪崩；
4. 运维——部署、滚动升级、监控告警链路全通，不是"开发机能跑就行"；
5. 退出成本——如果 3 个月后要回退，数据迁移 + 代码回滚预估工时 ≤ 1 人周。

第 5 条最容易被忽略，但恰恰是"PoC 跑通就上线"最致命的盲区——你进去容易，出来要命。我见过一个团队把消息中间件从 RabbitMQ 换到 Kafka，PoC 很顺利，一年后发现要迁回（业务量没起来、团队维护能力跟不上），光数据格式转换 + 消费者重写就花了 3 个人两周。

想听大家

• 你们团队的技术选型，"PoC 通过"的判据具体是什么？有没有踩过"PoC 没问题、上了生产就翻车"的坑？
• 什么场景下你们会接受"先上后补"（比如 PoC 只过了 gate 1 和 4 就先上）？
• 你觉得"必须写 ADR"是严谨还是过度工程化？小团队怎么在"留痕"和"别磨叽"之间找平衡？