技术选型的诚实时刻

一个不体面真相

大部分技术选型文章逻辑是这样：列出候选方案，逐一分析优劣，然后用一张对比表格得出”最优解”。

我之前也是这么写。后来回头看，发现那些分析基本都是事后找理由。真正让我做决定，往往是一些不太拿得上台面东西：当时的心情、前一天踩坑、某个教程写得好不好看、这个框架名字我喜不喜欢。

说出来有点丢人，但这就是事实。

第一次选型：Hexo

2022 年初搭博客，选 Hexo 的理由只有一个：中文教程多。

这不是一个技术理由，甚至算不上好理由。但当时我对 Node.js 生态一无所知，命令行也只会 cd 和 ls，能照着教程一步步跑通比什么都重要。

Hexo 的主题生态确实丰富，但”丰富”的另一面是”选择困难”。我换过三个主题，每个都用不到两个月就腻了。不是因为主题不好，是因为每个主题都有让我不舒服细节—字体太小、行距太窄、代码块没有复制按钮、目录不支持滚动定位。

现在回头看，这些问题大部分可以通过改 CSS 解决。但当时我不会，也不想学。所以最简单办法就是换主题。

这是技术选型第一个陷阱：当你的能力不足以定制时，“选择”就变成了”换”。

第二次选型：WordPress

用了大概半年 Hexo 之后，我动了换 WordPress 的念头。理由也很朴素：我想在手机上写文章。

Hexo 是静态站点生成器，写文章要开电脑、打开终端、新建 md 文件、写完 build、push。WordPress 有后台，手机浏览器打开就能写，写完点发布。

这个理由站得住脚。但后面发生事我没预料到。

WordPress 的插件体系是双刃剑。装了十几个插件之后，页面加载从 1.5 秒变成了 4 秒。优化了半天，发现最慢插件是评论通知和 SEO 分析—两个我用不太上功能。

更麻烦是数据迁移。从 Hexo 迁到 WordPress，我用的导出插件丢了一半文章分类信息。手动修了两天，中间数据库编码还出了问题，差点把整站搞挂。

这件事让我明白了一件事：迁移成本是技术选型里最容易低估变量。 选型的时候想是”新方案多好”，搬家的时候才发现旧数据才是大头。

第三次选型：Hugo

Hugo 打动我点是构建速度。Hexo 生成 200 篇文章要 8 秒，Hugo 只要 0.3 秒。

这个对比很打动人，但它回答了一个我不太关心问题。我的博客 200 篇文章，8 秒和 0.3 秒的区别只存在于 npm run build 和 hugo 之间—两个命令我都只在发布新文章时跑一次。

真正影响我日常体验是模板语法。Hugo 用 Go template，逻辑写法是 {{ if eq .Params.draft true }} 这种。我不写 Go，这套语法对我没有直觉。改一个侧边栏布局，我要查三遍文档。

这件事教会我：工具的绝对性能没有上手难度重要。 8 秒和 0.3 秒的差异，远不如”我想改个布局五分钟能搞定”和”改个布局要查半天文档”的差异大。

用了三个月，我又换回来了。

第四次选型：Astro

选 Astro 的过程比前几次都短。理由也不那么”技术”。

我需要一个满足以下条件框架：

1. 生成静态站，部署到 Cloudflare Pages 不花钱
2. 模板语法我看得懂（JSX-like）
3. 支持 MDX，能在文章里插组件
4. 不强制用 React 或 Vue

Astro 全都满足，但说实话，如果当时还有一个别框架也满足这四条，我大概率也会选。这不是一个”精心比较后得出最优解”，而是”第一个够用方案”。

后来证明 Astro 有一些让我头疼地方。Scoped CSS 和动态 DOM 的冲突我踩了不下五次，MDX 里导入组件路径解析出过莫名其妙 bug，Cloudflare 适配器 wrangler 配置每次 build 之后还要跑脚本清洗。

但我没有换。不是因为我说服了，是因为我累了。

折腾了三年博客之后，我对”框架”这件事态度发生了变化。框架是工具，不是信仰。它够用就行，不够用地方我花时间改，而不是花时间换。

没说出口那些理由

回头看这四次选型，真正的决策因素很少出现在我对外说理由里：

我说的	我没说
Hexo 生态成熟	中文教程最多，我怕看不懂英文文档
WordPress 有后台	我想躺在床上用手机发文
Hugo 构建快	我被 Hexo 的构建速度烦到了
Astro 支持多框架	我只用了它最基础功能

技术选型文章容易写成”理性决策”的叙事，好像每一步都是权衡利弊结果。但，很多决策是在信息不充分、时间有限、情绪驱动下做。承认这一点不丢人。

一个简单判断标准

我现在判断一个技术方案是否适合自己，只看一个问题：出了问题，我能不能自己修？

这说当框架行为不符合预期时，我有没有能力定位问题、读懂源码、改掉它。

Astro 的源码我能看懂大部分，出了 bug 我能定位到组件级别。Hugo 的 Go template 我看不懂，出了问题只能等别人修或者换方案。这个差异，比任何性能对比都重要。

这个标准有前提：你得知道自己能力边界在哪里。如果你 JavaScript 水平只够改配置文件，那选 Astro 可能反而不如选 WordPress—至少 WordPress 的后台能让你绕开代码。

技术选型没有银弹，只有适不适合。而”适不适合”这件事，只有你自己知道。

说一个反直觉事

我见过很多个人项目在选型上花时间比写代码时间还长。比较框架、跑 benchmark、画架构图、写选型文档—一套下来，项目还没开始写就已经累了。

后来我发现一个规律：选型花时间越长，项目完成可能性越低。因为长时间选型是在回避一个更难问题—你到底要做什么。

先做出来，难用了再换。这个策略不优雅，但有效。