为什么最后是静态站点

先说结论：选了 Hugo，输出纯静态 HTML，nginx 直接发。

WordPress 那边的问题

WordPress 是默认答案，它的好处也真实存在：后台写文章、插件生态、评论、搜索，全套现成。

但在一台 3.8G 内存的小机器上，这套「现成」要付的账是这样的：

• PHP-FPM + MySQL 常驻，空闲时也吃几百兆
• 插件和核心要跟着安全更新走，一次更新失败可能白屏
• 备份要备份数据库，不是备份一堆文件
• 公网上暴露 wp-login.php，会持续收到撞库请求，日志里一眼就能看出来

这些都不难，只是每一件都需要我记得。而我想要的是一台「配好就不用管」的机器。

我到底需要什么

把需求写下来之后更清楚了：只写，只发。

不需要后台（改文件比点按钮快），不需要评论（想讨论的人会找到别的方式），不需要多作者，不需要登录。既然一样都不需要，那套后台就不是资产，是负债。

静态站的形状

Markdown 文件  →  hugo  →  一堆 HTML  →  nginx 发出去

写文章就是新建一个 .md，构建一次，完事。

选 Hugo 而不是 Hexo / Astro，理由很实际：它是单个二进制文件。不需要 Node，不需要 npm install，不需要几百兆的 node_modules，不需要担心某个依赖三年后装不上。21M 的一个可执行文件丢进 /usr/local/bin，hugo version 能出来，环境就好了。

构建也快。这个站点目前六七个页面，构建时间在一秒以内，快到不用考虑「要不要增量构建」这种问题。

代价也得说清楚

静态站不是没有成本，只是把成本挪到了别处：

1. 写完要重建。 手动敲一次 hugo。用脚本包一层就不算问题了。
2. 没有评论。 真要的话得外挂第三方服务，那就又把「依赖别人」请回来了。
3. 没有搜索。 页面少了用不上，真需要再加。
4. 写作环境在服务器上。 想在任何地方写，就得考虑同步，比如把内容目录放进 git。

四条里只有前两条现在真的会碰到，后两条等它变成问题再说。

一句判断

技术选型里最好用的标准，不是「哪个更强」，而是「哪个的成本我能长期付得起」。对这台机器、这个写作频率、这个不愿意半夜起来修站的我来说，静态站是唯一一个成本我付得起的方案。