从 HTML 到 Hugo：我第一次选择静态博客的原因

刚开始准备搭博客的时候，我的想法其实很简单：先写一个能访问的网页出来。HTML、CSS、JavaScript 这些基础技术栈最直接，也最容易理解。页面长什么样，按钮放哪里，文字怎么排版，都可以自己控制。

这个想法在一开始很有吸引力。因为它没有太多前置条件，也不需要考虑复杂架构。写几个页面，放到服务器上，用 Nginx 托管，域名解析过去，一个最简单的网站就出来了。

手写页面的问题很快暴露出来

但继续想下去，我发现手写静态页面只适合起步，不太适合长期维护博客。博客不是只有首页，还会有文章列表、文章详情、分类、标签、归档、关于页面。每发一篇文章，都要手动改列表、改链接、维护页面结构。文章一多，这件事会变得很琐碎。

如果只是做一个展示页，手写 HTML 没问题。但如果目标是持续写文章，它的维护成本会慢慢堆起来。这个阶段我意识到，博客系统不只是“能打开一个网页”，更重要的是以后发文章时不要太痛苦。

当时我的 VPS 只有 1G 内存。这个配置不算宽裕，如果同时跑 Java 后端、MySQL、Jenkins，再加上一些其他服务，很容易把服务器压得很紧。网站刚开始还没什么内容，我也不想一上来就把架构搞得很重。

所以我开始考虑 Hugo。Hugo 是静态博客生成器，写文章时用 Markdown，生成后就是一批静态文件。最终线上运行时不需要后端服务，不需要数据库，Nginx 直接托管就能访问。对 1G VPS 来说，这是一种非常稳妥的选择。

当时我设想的流程是：本地或仓库里维护 Hugo 项目，提交文章后由 Jenkins 拉取代码、执行构建，再把生成的静态文件部署到 Nginx 目录。访问链路很清楚，资源占用也很低。

这个方案的优点很明显：页面访问快，服务器压力小，部署结构简单，不容易出复杂问题。对于只是写文章和展示内容来说，Hugo 足够可靠。尤其是在服务器资源有限的时候，它确实是一个现实的选择。

不过继续推演之后，我也看到了静态博客的边界。它缺少后台管理，文章发布不够可视化；如果以后要评论、搜索、插件、主题后台配置，往往需要额外接很多东西。不是不能做，而是会逐渐从“轻量”变成“拼装”。

我也担心自己后面会把时间花在维护构建流程和各种周边能力上，而不是写文章本身。Hugo 很适合轻量博客，但如果我想要一个更像正式网站的体验，它可能不是最终答案。

所以 Hugo 是我第一次认真选择的方案，但不是最后的方案。它让我想清楚了一件事：在资源有限时，轻量和稳定非常重要；但当目标变成“长期管理内容、可视化发布、后续可扩展”时，我还需要重新评估。

这也是后来我升级 VPS、考虑 Vue + Java，再最终转向 Halo 的原因。每一步都不是完全否定前一步，而是在新的目标和条件下重新做取舍。