技术选型，我是怎么做决定的
上周有人在我博客评论区问：「你为什么选 Hexo 而不是 Hugo？」
我想了半天，给了个不太令人满意的答案——「因为当时这个我更熟悉」。
但事后我想，这其实是个挺值得认真回答的问题。技术选型是每个程序员都要反复面对的事，但我们却很少把「怎么做决定」这件事本身想清楚。
我最近用 AI 回顾了自己过去几年的几十个技术决策，发现确实有一些思维模式在里面——有些是主动选择的，有些是踩坑之后总结出来的。这篇文章就是把这些东西写出来。
不保证适用于所有人，也不是最优解，就是我自己用着顺手的那套。
先搞清楚「选型的成本」
很多人做技术选型时，会先问：这个技术好不好？功能够不够？但我觉得更重要的前置问题是：这个选型的切换成本有多高？
切换成本低的技术，可以稍微大胆一点，可以试错，可以随时换。切换成本高的技术，就要保守得多，要把方案想得更清楚再下手。
比如我选博客框架：Hexo 换 Hugo 的成本其实不算高，Markdown 文件可以复用，主题配置重来一遍，最多折腾一周。但如果当年给公司选了某个特别定制化的 ORM 框架，三年后想换，基本是重写。
所以决策谨慎程度要和切换成本成正比，这是我的第一个原则。
「我熟悉」不是理由，但也没那么糟
回到刚才那个问题：为什么选 Hexo 而不是 Hugo？
「因为我熟悉」确实不是一个体面的技术理由。但我现在不觉得这个答案完全错了。
有一条经验是：在个人项目和时间有限的情况下，降低学习成本是完全合理的权衡。 选一个你 70% 熟悉的技术，和选一个「理论上更好」但你需要花两周学的技术，哪个能让你更快把东西做出来、做出来之后维护起来更顺，这才是个人开发者需要权衡的核心。
这跟团队项目不一样。团队项目要考虑招聘、传承、协作，「我熟悉」就显得太自私了。但对于个人项目，这是一个合理的理由。
当然，「我熟悉」的前提是：你熟悉的那个技术至少不会是个坑。如果你只熟悉一个早就没人维护的 2014 年框架，那可能要逼自己跨出舒适区了。
三个我真正在用的过滤维度
真正到做选型的时候，我会过三关：
第一关：这个技术的社区还活跃吗？
不需要看什么 GitHub Star 数，就看两件事：最近三个月有没有提交？官方文档有没有在更新？如果一个技术的最后一次 commit 是两年前，那无论它当年有多好，我都不会在新项目里用它。
以前用过一个很好用的 Python 异步库，结果后来作者消失了，碰到问题只能靠自己 fork 修。那种感觉很糟糕，就像租了一栋房子，房东跑路了，水管坏了没人修。
第二关：有没有「正常人」在生产环境用？
这不是在说要等别人踩完坑。而是说，如果一个技术只有一两家公司在用，那遇到边界案例的时候，文档里不会有答案，StackOverflow 上不会有回复，你就是那个最孤独的人。
我看「生产环境实践」的方式很简单：搜这个技术名 + “production” 或者 “in production”，看看有没有真实案例，规模大不大，踩的坑是不是我能接受的。
第三关：它的核心抽象和我的问题匹配吗？
这是最考验判断力的一关。
每个框架和工具都有它的核心抽象——它认为「世界应该是这样运转的」。如果你的问题符合这个抽象，用起来会顺水推舟；如果你的问题和这个抽象天然冲突，你会发现自己在不断「打破框架」。
比如 React 的核心抽象是「UI 是状态的函数」。如果你的界面主要是数据展示、状态驱动，React 是顺手的。但如果你的界面充满了命令式的动画、DOM 操作，React 用起来就会有种拿锤子拧螺丝的感觉。
这一关没有捷径，只能靠写几个 demo 感受，或者找真正在生产环境用过它的人聊。
AI 改变了选型过程的哪些部分
用了一年多 AI 辅助工作，回头看我自己的选型流程，有几个地方变了：
调研速度快了很多。 以前「快速调研一个框架」可能需要半天时间，现在用 AI 把关键维度列出来、把常见 tradeoff 梳理清楚，通常一小时内可以有个比较清晰的轮廓。
但有一个地方我用 AI 用得很谨慎：让它帮我做最终判断。
AI 给的建议很理性，条条有理，但它不知道你们团队的具体情况，不知道你上一个项目踩的是什么坑，不知道你的老板对新技术的接受度。它可以帮你看得更全，但最后那个「我选这个」的按钮，还得你自己按。
我现在的用法是：让 AI 帮我列出我没想到的维度，帮我检查有没有明显的盲点，但判断权我自己留着。
一个我后来改变主意的决策
2024 年初我在做一个内部工具，需要选 UI 框架。当时我选了一个「设计很好看、组件很丰富」的选项，但用了三个月之后，维护起来越来越痛苦——因为它的定制化能力很弱，我需要实现的一些特殊交互，要绕很多弯路。
最后我们把这套 UI 层推翻重做了，代价是差不多两周的工时。
事后复盘，我发现我在那次选型里犯了一个典型错误：被 demo 体验迷住了，忽视了「实际项目中的定制需求会有多少」这个问题。 Demo 永远是最好看的，所有文档示例都是把框架用在最擅长的场景里。
现在我做选型，会专门问自己：「这个技术在它最不擅长的地方会怎样？」
技术选型没有标准答案。同样的项目，在不同的团队、不同的时间点，最优解可能是完全不一样的东西。
我这套框架说白了就是：控制切换成本 → 过三关筛选 → 用 AI 查漏补缺 → 但最终判断自己负责。
不够体面，但用着踏实。
如果你有不同的选型思路，欢迎在评论区分享——我现在还在 Hexo，但随时准备被说服。