部署博客的三种方式

静态博客有一个不太被提起的成本：发布。

写作本身是线性的，打开编辑器，把想法写下来，关掉。发布不是。它要构建、要上传、要确认线上那台机器上发生的事和你本地看到的一样。这条链路我前后改过三次，最后一次才想清楚自己在权衡什么。

一开始，我把构建交给了 CI

最开始的方案是 GitHub Actions。push 之后自动构建，构建完 rsync 到服务器。好处很直接：不用管，换台电脑也能发文章。

问题出现在两个地方。一是反馈太慢，一个错别字从提交到线上看到结果，要等一分多钟。二是权限，仓库里存着部署私钥，等于把服务器的钥匙复制了一份放到云端。对个人博客来说这未必不能接受，但我不太喜欢这种感觉。

还有一个很小但频繁的摩擦：为了改一个标点，也要写一条 commit。时间久了，提交记录里全是“update post”，回头看的时候什么都看不出来。

Git Hook：把构建挪到服务器

后来我试了更古典的做法：服务器上放一个 bare 仓库，push 触发 post-receive 钩子，检出代码、安装依赖、执行构建。

# /srv/git/blog.git/hooks/post-receive
GIT_WORK_TREE=/srv/blog git checkout -f
cd /srv/blog
npm ci --omit=dev
npx hexo generate

这套方案最迷人的地方是“push 即发布”，一条命令结束。代价也很清楚：服务器要装 Node，要能访问 npm，构建的时候内存和 CPU 会抖一下。更麻烦的是失败形态，构建中途出错，线上目录可能只更新了一半，而你不在现场。

我遇到过两次。一次是主题依赖升级后构建失败，首页变成了空白；另一次是磁盘满了，写了一半的 HTML 留在目录里。两次都只能 ssh 上去手工回滚。

把构建放在哪台机器上，本质上是在选择让哪种失败发生在自己看得见的地方。

现在我回到本地构建

现在我在本地执行 hexo generate，检查一遍 public/，再 rsync 上去。

rsync -az --delete public/ deploy@host:/var/www/blog/

服务器只做一件事：把文件发出去。没有 Node，没有依赖，没有构建日志。发布慢了三十秒，但我能在上传之前看到生成结果。

代价是环境绑在这台电脑上。换机器要重新装 Node 和主题依赖，手机上基本没法发文章。这也是我最后仍然保留了一个手动流程的原因：它逼我在发布前看一眼。

我的检查清单很短：本地预览打开首页和任意一篇文章，确认代码块没有溢出，确认日期和标题正确，然后才执行发布。四步，不到一分钟，但拦下过好几次低级错误。

我没法说哪一种方案是正确答案。Git Hook 适合一个人、一台机器、频繁发布；本地构建适合发布不频繁、但希望每一步都可控的人。我目前属于后者。

这套流程用了大半年，唯一还想改的是构建速度。至于“最优雅的方案”，我越来越觉得它不存在，存在的只是你愿意长期承担的那部分麻烦。