做这个站之前，我花了大概三周时间试方案。不是选择困难，是每种方案都真的动手跑了一遍， 然后一个个被自己否掉。最后落地的结果很简单：五个 HTML 文件，一份 CSS，一个不到 60 行的 JS。

方案一：WordPress

第一个想到的是 WordPress，毕竟它就是为博客生的。装完确实爽——后台有了，主题商店里挑一个， 发文章只要打字。但用了两天我就开始烦。

问题不在 WP 本身，在于它把一个「个人网站」变成了一套「需要运维的系统」。 要装 PHP、要连数据库、插件要更新、更新完可能冲突、有安全补丁要打。 我服务器只有 2G 内存，MySQL 常驻就吃掉一大块。 最要命的是：我一年写几十篇文章，却要长期维护一个随时可能出问题的系统，这个投入产出比不对。

还有个隐性成本：WP 站是动态渲染的，每次访问都要跑 PHP 查数据库。 访问量小的时候没感觉，但一旦被爬虫扫到，CPU 就上去了。加缓存插件？那又回到「维护更多东西」的老路上。

方案二：前端框架脚手架

第二个想法是用 Vue 或者 React 搭。理由很正当：我本来就在学这些，正好练手。 脚手架一装，目录结构、路由、组件化，看着确实专业。

但我盯着屏幕上那五张静态页面，突然觉得有点荒谬： 为了展示五页几乎不变的内容，我要维护一整个 node_modules。

这不是矫情。前端生态的更新速度意味着，两年后我回来改一个错别字， 很可能 `npm install` 直接报一堆 peer dependency 冲突，得花半天修依赖。 而那时候我可能已经忘了这个项目是怎么配的。

框架本身没错，错的是场景。框架解决的是「状态复杂、交互频繁」的问题。 我这个站连一个表单都没有，要状态管理干什么。

方案三：现成模板

第三个方案最省事：找个好看的 HTML 模板，把文字换掉。我下了几个，改到一半就放弃了。

原因是结构不合。模板作者设计的板块顺序、字号层级、留白节奏，都是为「他想象中的内容」服务的。 我的内容塞进去，要么某块永远空着，要么得把内容硬拆成他的格式。 改到最后，代码里一半是模板的残留样式，删也不敢删——比自己写还费劲。

用别人的结构装自己的内容，最后往往是两头都不像。

所以：手写

三个方案都否掉之后，答案反而清楚了。我需要的不是一套系统，是一批文件。 于是有了现在这个站：每页一个 HTML，共享一份 CSS，JS 只负责移动端菜单开合和滚动淡入。

换来了什么

  • 零运维。没有数据库、没有运行时、没有后台。服务器只需要装个 Nginx 指向目录，之后半年不用管。不存在「被拖库」这种风险，因为根本没有库。
  • 快。一次请求返回一个已经写好的 HTML 文件，首字节时间基本等于网络往返。没有渲染等待，没有接口请求。
  • 十年后还能打开。HTML 和 CSS 是浏览器的母语。2010 年写的静态页今天照样能看，而 2018 年的某个构建工具现在可能装都装不上。
  • 改一处生效一处。配色改了，改 CSS 变量；导航加一项，五个文件替换一下。没有编译、没有缓存、没有构建产物。

付出了什么

  • 加文章要手动复制模板。新建文件、改标题、改导航高亮、更新列表页——大概五分钟。我一年写几十篇，这个成本可以接受。如果我是日更，那就该换生成器了。
  • 没有动态能力。搜索、标签筛选、评论，全都做不了。但这个站本来就不需要——个人站的价值在内容，不在功能多。
  • 导航改一次要改五个文件。这是最大的痛点。解决办法是别老改导航，定下来就别动。

如果重来一次，我会怎么选

我的判断标准现在很明确：看内容更新频率。

  • 日更或周更（几十篇以上）：用手写会疯掉。这时候该上静态站点生成器，比如 Hugo 或者 11ty——写 Markdown，构建出静态文件，既有静态的好处，又不用手动维护页面。
  • 月更或更慢：手写。文件少、改得少，任何工具带来的复杂度都超过它省下的时间。
  • 需要多人协作、有复杂交互：那老实上框架，静态方案确实不适合。

技术选型最怕的不是选错，是「因为流行所以选」。 对我来说，一个个人站最重要的是它一直在，而且我随时能改。 手写恰好最满足这两条。