为什么我把个人站点做成了纯静态
这个站点去年刚买域名时，我装的是一个常见的动态博客程序，跑了一年多。今年国庆把它全部换成了静态 HTML，页面数量和现在这样差不多。决定动手的不是它不好用，而是有天我出差回来发现站点打不开，Remote 上去一看：程序后台在等一个安全更新，而我不知道该点哪个按钮。
让我改主意的四件事
一、维护成本比写文章高
一年里我真正发布的内容不到十篇，但为了这套程序做的事包括：升级运行环境、修插件兼容性、跟 PHP 版本、清理被扫描器塞满的日志。有一阵子每次 SSH 上去都是先处理它，写完文章的成就感全被消耗掉了。对个人站点来说，写内容才是目的，剩下的都应该越少越好。
二、备份变成了「一套系统」而不是一份文件
动态站点的备份至少包含三部分，少任何一块，恢复出来的就不是原来那个站：
| 备份对象 | 动态博客 | 纯静态 |
|---|---|---|
| 内容正文 | 数据库表，需要导出 SQL | 就是 HTML 文件本身 |
| 上传的图片 | 媒体目录 + 路径映射 | 随文件一起走 |
| 可运行环境 | 运行时版本 + 扩展 + 配置 | 无 |
静态站的备份就是 cp -r 加一次 git push。我现在的习惯是本地一份、git 远端一份，任何时候换服务器都只是把文件拷过去，不需要重新装环境。
三、速度不再是「优化出来」的
以前我为了首屏时间做过一堆事：加缓存插件、开 OPcache、调数据库索引、上 CDN，测下来首页从 900ms 降到 350ms，但每次升级之后还得再测一遍确认没退化。静态页不需要这些——一个 HTML 加一个 CSS，浏览器直接就能渲染。
<!-- 整个站点的全部依赖，就这两行 -->
<link rel="icon" href="assets/favicon.svg" type="image/svg+xml">
<link rel="stylesheet" href="assets/style.css">没有 JS 这件事带来的收益比压缩图片更明显：浏览器不用等脚本执行完才敢画屏幕，也不会有布局抖动。
四、能被攻击的面小了很多
动态站点摆在外网的东西包括登录入口、插件执行路径、数据库连接和一堆历史 CVE。纯静态站点没有任何输入口：没有表单、没有登录、没有可以执行的脚本。服务器被攻破的可能性主要转移到「托管方是否更新了 Web 服务」这一层，而这件事不归我操心。
换静态之后我第一件事是关掉了服务器上所有多余端口，只留 80 和 443，同时把 SSH 从密码登录改成密钥。
这么做我放弃了什么
说清楚代价，不然这段记录没有参考价值：
- 没有评论。我试过第三方的评论服务，但那意味着往页面里塞一段别人的 JS，而且它一旦停服，历史评论就没了。最后我把「评论区」换成了关于页里的邮箱。
- 不能在线改。发新内容必须本地改文件、提交、推上去，手机临时想写一段是不行的。对我来说这反而过滤掉了六成「不值得发」的念头。
- 没有分类聚合、搜索。全站靠归档页一个时间线，内容多了得自己加索引页。目前 9 条，还不需要。
- RSS 要自己维护。我试过手写一份
feed.xml，每次新增都要改两处，容易漏。最后决定不做订阅。
目录为什么长这样
没有用任何静态生成器，目录直接就是最终部署的目录，链接全用相对路径——这样本地双击 index.html 就能完整浏览，传到任何虚拟主机或对象存储也不需要配伪静态。
web/
index.html 首页
blog/ 成篇文章，列表页 + 每篇一个 html
notes/ 速查笔记，同上
archive.html 全部内容的按时间归档
about.html 关于
privacy.html 站点数据说明
404.html 找不到页面
assets/ 一个 style.css 加两个 svg一个细节：所有子目录页面里的资源路径都写成 ../assets/style.css，而不是从根开始的 /assets/。原因是这份文件如果被放到某个子路径下（比如临时用 IP 加目录访问），绝对路径会全部 404，相对路径不会。
小结
纯静态不是「更高级」，只是更适合我这种「一两个月写一篇、不想为它维护一套服务」的用法。如果你需要在线协作、频繁更新或者要评论互动，动态程序仍然是对的选择——只是别把它的维护成本当成理所当然。
写完这一篇，我的更新频率可能会掉到三个月一次，因为这个站再也没有需要修的东西了。这大概就是它最好的样子。