技术的选型

做一个东西，可选的路线永远不止一条：用现成的还是自己写、追新还是用稳的、一步到位还是先凑合、顺手还是"更正确"。我在选型上栽过跟头，也见过别人栽——绝大多数翻车不是因为选错了技术，而是因为在选这件事上花了太久，或者选完了又反复横跳。这篇把我的判断方式整理成一套可复用的流程，不讲道理，只讲我实际怎么下决定。

一、先接受一件事：选型是取舍，不是找最优

我刚做技术选择的时候有个执念：一定存在一个"最正确"的方案，我要把它找出来。结果每次都在比较中耗掉大量时间，最后往往还是选了最熟的那个——而且过程中什么产出都没有。

后来想明白了：选型是取舍，不是求解。任何方案都是"在这个维度上得到，在那个维度上付出"。你不可能同时要上手快、性能高、生态全、部署简单——这四样凑不齐，因为它们本身互相冲突。

示意：同一个方案，四个维度不可能全是高分

所以选型真正要回答的问题不是"哪个最好"，而是"在我这件事里、在这个阶段，哪个维度的损失我能接受"。这个问题一旦问对，答案往往几分钟就出来了。

二、我下决定前会问的四个问题

1. 这个决定影响的是"这件事的成败"，还是只是"我写得舒不舒服"？九成的技术选择属于后者。而后者不值得花超过十分钟。把精力留给真正决定成败的那 10%。
2. 现在就必须定下来吗？很多选择可以推迟。先用最熟的方式把东西做出来，等真的有反馈、真的知道瓶颈在哪，那时候再定也不迟——而且那时候你掌握的信息比现在多得多。
3. 如果它出问题了，我知道怎么救吗？这是我最在意的一条。陌生的东西不是不能用，而是别在不能出错的位置上第一次用它。第一次上手新东西，最好是在一个"搞砸了也无所谓"的地方。
4. 万一这条路走不通，我能退回哪？这个问题决定了你要不要在第一版就把它做死。如果退路清楚，那可以大胆试；如果退不回去，那就保守一点。

三、几类常见取舍，我是怎么站的

抽象的原则说多了没用，我挑几类每次都遇到的，直接给结论：

四、反过来：什么时候不要换

这部分其实比"怎么选"更重要，因为"反复换"是最常见、也最昂贵的错误。

• 现在的方案还没真正用起来的时候，不换。很多"它不行"的判断，其实是"我还没用它做成过任何东西"。这种情况下换什么都会遇到同样的问题。
• 痛点还没被定位到具体位置的时候，不换。"感觉太慢了"不是理由，"卡在这一行计算上，占了总耗时的八成"才是。没定位就换，等于闭着眼睛换零件。
• 单纯因为"听说那门技术更火"的时候，不换。热门和适合你手上的问题，是两件无关的事。
• 手上同时有两个东西在做的时候，不换。换东西需要连续的时间和注意力，碎片化的时间只会让两边都推进不了。

我给自己定过一条很实用的纪律：任何"要不要换"的决定，至少放三天再下。三天之后如果还是觉得必须换，那就换；大多数情况下，三天之后你会发现问题已经绕过去了，或者发现真正该改的是别处。

五、"留退路"具体怎么做

"留退路"听起来虚，其实有几个很具体的操作，我基本每次都做：

• 让各部分之间松一点。数据存哪、怎么调、怎么配置，尽量标准化。这样以后换掉其中一块时，只动一块，不用整体推倒。
• 会变的都别写死。路径、地址、开关、阈值全部提到外面。这条平时看着啰嗦，真要换的时候能省掉一整天。
• 重要的改动前先备份。几乎零成本，但能让你敢于大胆改——因为你随时能退回去。
• 把"为什么选它"写下来。哪怕只有三行。半年后你要不要换的时候，这份记录决定你是"有的放矢地改"还是"重新纠结一遍"。