纯静态博客最吸引我的地方，是文件清楚、部署直接：文章在本地写完，生成 HTML，再把整个目录上传到服务器。不过文章慢慢增多以后，手工步骤也会悄悄变多。某次忘记更新文章列表，某次复制了错误目录，还有一次页面能打开，导航里的链接却指向旧地址。它们都不算复杂故障，却足以让一次原本轻松的发布变得反复。
于是我给博客补了一套很小的自动化流程。它不依赖持续运行的服务，也没有复杂的发布平台，只是把每次都要做的事情固定下来：读取 Markdown、生成站点、执行检查，最后得到一个可以直接上传的目录。
让 Markdown 成为唯一内容来源
我把每篇文章保存为独立的 Markdown 文件，文件开头记录标题、日期、分类、摘要和固定链接。首页、分类页、RSS 与站点地图都从这些字段生成，不再分别手工维护。这样修改发布日期时，只改一处就够了，也不会出现首页日期和文章页日期不一致的情况。
文章正文仍然是普通文本，可以用任何编辑器打开。图片放在统一的资源目录里，正文只记录相对路径。即使以后更换生成工具，内容本身也容易迁移，不会被某个后台数据库锁住。
用一个入口完成整个构建
构建脚本不需要写得很庞大。我只保留一个明确入口，例如运行 npm run build，脚本先清空临时输出，再读取文章、套用页面模板、复制样式和图片，最后生成完整站点。构建失败时立即返回错误，不继续留下一个看似完整、实际缺文件的目录。
我还会让输出目录保持可丢弃：里面的文件全部由脚本生成，不在其中直接修改内容。需要调整页面，就去改模板或样式源文件，然后重新构建。这个约定避免了“线上版本改过，但本地找不到修改”的尴尬，也让备份范围更明确。
在上传前检查链接与元数据
网页成功生成，并不代表它已经适合发布。脚本会继续做几项成本很低的检查：每篇文章是否有标题和日期，slug 是否重复，日期格式是否正确，摘要是否为空，正文引用的本地图片是否存在。对于站内链接，则确认目标文件确实出现在输出目录中。
这些规则不追求覆盖所有问题，而是优先拦住最常见的疏漏。比如重复 slug 会导致文章互相覆盖，缺少标题会让浏览器标签和文章列表变得难以识别，错误图片路径则会留下明显的空白。检查结果应当指出具体文件和字段，让修正过程足够直接。
保留一份发布前清单
自动检查之后，我仍然会做一次简短的人工确认。先在本地打开首页和新文章，查看手机宽度下是否正常；再确认文章排序、导航、版权年份和备案信息；最后检查输出目录里没有草稿、临时截图或编辑器缓存。上传前还会保存当前线上目录的副本，便于出现问题时快速恢复。
这份清单不必很长，关键是每次发布都按同样顺序执行。脚本负责确定性强、容易重复的工作，人负责阅读体验和页面观感。两者分工以后，发布会比单纯依赖记忆可靠得多。
自动化到刚刚好
个人博客没有必要一开始就引入容器集群、复杂流水线和多套环境。只要发布频率不高，本地一键构建、自动检查，再手工上传，已经能解决大部分问题。工具越多，升级和排错的对象也越多，维护负担可能反过来超过写作本身。
我判断是否增加新步骤的标准很简单：同一种错误是否真的发生过，某项操作是否经常重复，以及自动化后能否更容易理解。如果答案都是否定的，就先保持现状。对纯静态博客而言，最好的流程不是最先进的流程，而是半年以后回来，仍然敢于运行、知道结果在哪里，也能安心把时间继续花在文章上。