博客框架选型思考：Hugo 为什么是答案
选型不是选功能最多的，而是选取舍最贴合自己需求的。
需求本质
先想清楚：我要的是什么？
- 写文字，不需要动态交互
- 内容在 Markdown，不想迁数据库
- 部署越简单越好，最好推完 Git 就上线
- 主题要简洁，不要花里胡哨
本质：这是一个内容发布问题，不是 Web 应用问题。
为什么不是 Hexo
Hexo 也能用，但有个根本问题：它是 Node.js 写的。
不是说 Node 不好，而是：
- 每次写文章，本地要
npm install，依赖一多就慢 - 主题生态碎片化，质量参差
- 构建速度在文章多了以后会明显下降
核心取舍：Hexo 把"主题生态"放在前面，代价是"维护成本"。我更想要后者低。
为什么不是 Next.js / Gatsby
这类框架能做更多事——SSR、ISR、CMS 集成……
但问题也正是能做太多。
- 配置复杂，next.config.js 能写几百行
- 部署要管 Node 服务，或者用 Vercel
- 写篇文章要启动 dev server，等热更新
核心判断：如果我开始折腾配置的时间比写文章多，这个工具就选错了。
Hugo 为什么贴合
Hugo 的设计哲学是：一个二进制文件，搞定所有事。
| 维度 | Hugo 的答案 |
|---|---|
| 构建速度 | Go 写的，几千篇文章毫秒级构建 |
| 依赖管理 | 不需要 node_modules，下载即能用 |
| 部署 | 生成纯静态 HTML，放哪里都能跑 |
| 主题 | 单目录，不依赖 npm |
| 写作体验 | hugo new，写完 git push，完事 |
它认清楚了自己的定位：我是内容发布工具，不是应用框架。
选型背后的道
回顾这个过程，选型的本质是三件事：
- 想清楚自己要什么 — 不要被"功能多"迷惑
- 看清工具的定位 — Hugo 是发布工具，Next.js 是应用框架，它们解决的是不同维度的问题
- 为取舍买单 — 选了 Hugo，就接受了"不能 SSR、不能动态交互"；但这是我不需要的东西，所以无所谓
真正的选型能力，不是知道哪个更强，而是知道哪个的取舍最贴合自己的场景。
后记
博客搭完以后，确实没再碰过 Hugo 的配置。
这可能就是最好的工具——它在那里，你不用想着它。