我做技术选型有一张表。不是为了显得专业，是因为我吃过亏——2017 年我凭「感觉更现代」选了一个当时很火的存储方案，八个月后那个项目的维护者宣布停止更新，我们花了六周迁移出去。
从那之后我给自己定了五个维度，每个 1 到 5 分，加权算总分。这篇就讲这张表，以及它失效的时候。
维度一：退出成本（权重最高）
我问的第一个问题永远不是「它好不好」，而是「如果它不行了，我要花多久换掉」。
判断方法很朴素：这个技术在我的代码里会出现多少次？如果是一个消息队列客户端，我可以用一层薄封装把它圈起来，退出成本低，给 5 分。如果是一个侵入到每个实体类的 ORM 或者一套自定义注解，那它会长进代码的每个毛孔里，1 分。
去年选一个全文检索方案时，我就是靠这一条把选项从 4 个砍到 2 个。
维度二：故障时我能不能自救
具体问题：出问题时我能不能读懂它的源码？它的日志说人话吗？有没有办法在本地复现？
我评估过一个国外的分布式调度组件，功能很漂亮，但它的错误信息只有一串枚举码，文档里没有对照表，源码是我不熟悉的语言。我给了 2 分，最后没选。
相对地，有个方案功能少一半，但整个核心只有 6000 行代码，我花一个周末通读了一遍。这种「我完全掌握」的感觉，在凌晨三点值一百分。
维度三：团队的存量知识
这一条我以前严重低估。团队里 6 个人，5 个人熟悉 A，0 个人熟悉 B。就算 B 客观上好 20%，选 A 大概率仍然是对的。
因为技术的好坏是静态的，而团队的产出是动态的。学习曲线期间的产能损失和 bug 率上升，往往能吃掉那 20% 的优势好几倍。
我现在会明确算一笔账：新技术的学习成本 = 人数 × 上手周数 × 每周成本。6 个人 × 3 周，这不是小数目。
维度四：活跃度的真实信号
Star 数是最没用的指标。我看这几个：
- 最近 90 天的提交是不是只有版本号和依赖升级？
- issue 的平均首次响应时间是多少？我会随机点开 10 个 issue 数一下。
- 有没有除作者之外的第二个活跃维护者？单人项目风险很高。
- 有没有在文档里写清楚破坏性变更的策略？
2017 年那次翻车，如果我点开 issue 列表看一眼，就会发现半年内没有任何一条得到官方回复。我当时只看了首页的 star 数。
维度五：它解决的是不是我的真问题
这一条最容易被跳过。我见过太多次，包括我自己：明明日活三千，非要上一套为百万级设计的架构。
我现在会强迫自己写下当前的具体数字：QPS 多少、数据量多少、增长率多少、可接受的延迟是多少。然后问，现在这套东西是在哪个数字上撑不住了？
有一次我准备引入一个流处理引擎，写完数字之后发现，我们的「实时」需求实际上是每 5 分钟更新一次报表，一个定时任务加 SQL 就够了。省下了整整一个季度。
这张表什么时候会失效
坦白说，它有明显的保守偏向。按这张表打分，胜出的几乎总是「团队熟悉的、成熟的、无聊的」方案。
大多数时候这是对的。但有两种情况我会主动推翻它：
- 这个项目本身就是探索性的。如果一个东西的目的就是试水，风险容忍度高，那用新技术学到的东西本身就是产出。
- 老方案的痛已经可度量地压垮团队。比如某个环节每周稳定消耗两个人天，一年就是一百人天，这时候激进一点是划算的。
最后一句
选型这件事，我做了十年得出的最大心得是：你选的不是一个技术，是未来三年每周要面对它的自己。
所以我现在做完打分，还会做一件很主观的事——闭上眼睛想象一下，半年后的某个周三晚上，这个东西出故障了，我坐在电脑前的心情是什么样的。如果那个想象让我发慌，分数再高我也会再想想。