先构建再替换#

不要在原 dist 上边删边构建。更稳妥的做法是在临时目录构建完成，确认成功后再替换线上 dist，这样失败时不会把正在访问的网站清空。

1
pnpm install --frozen-lockfile
2
pnpm build
3
test -f dist/index.html

替换时保留旧版本#

上线前把旧 dist 改名保存，例如 dist.prev.20260701172501。如果新版本页面异常，可以快速切回旧目录。

线上验证#

• 首页返回 200。

• 修改过的文章 URL 返回 200。

• /api/allPostMeta.json 时间和数量更新。

• /pagefind/pagefind.js 可访问。

• Nginx 配置测试通过。

缓存问题#

如果服务器文件已经更新但浏览器仍显示旧页面，先用无痕窗口或强制刷新确认。不要急着重复部署，避免把缓存问题误判成构建失败。

实战复盘#

复盘《博客修改后的发布检查》时，我会把它当成一个站点维护动作，而不是单篇文章。凡是影响首页、分类、RSS、Sitemap、搜索索引或旧链接的改动，都要在发布后做一次线上验证。

如果只在源码里看起来正确，但线上接口或页面没有变化，就说明构建或发布链路还有问题。博客维护类内容必须把“怎么确认已经生效”写清楚。

以后继续扩展这类文章时，可以补充真实命令输出、截图前后的差异，以及回滚路径。这样文章会更接近操作手册，而不是零散备忘。

最小验收样例#

验收《博客修改后的发布检查》时，我会选一篇真实文章或一个真实页面作为样例，而不是只看源码。先确认页面能打开，再确认列表、分类、归档、搜索这些入口都能找到它。

如果文章讲的是站点维护，还要记录修改前后差异：改了哪个文件、构建产物是否更新、线上 HTTP 状态码是多少。这样后面出问题时，可以直接回到这次验收记录。

小结#

发布检查要看线上事实，不看感觉。构建日志、文件时间、HTTP 状态码和页面内容都确认后，才算真正完成上线。