一次部署事故复盘：两个检出互相覆盖，线上回到了昨天

上午做完了教程栏目重构，部署后核验过：新分组在线上渲染正常。一小时后看页面——又是旧版，连两小时前改的标题都消失了。这篇文章复盘这次排查和它暴露出来的流程问题。

症状：改了等于白改

症状有两层，第二层更迷惑人：

1. 重构部署后核验过，新结构在线上渲染正常——说明部署本身成功了；
2. 一小时后页面变回旧版，连更早改的文章标题也一起消失了——说明有别的部署把它覆盖了，而且覆盖者比重构还旧。

排查：部署记录不会说谎

Cloudflare Pages 的部署列表就是时间线。wrangler pages deployment list 拉出来一看，最近四次生产部署来自三个不同的 commit：

5 分钟前   d355976  ← 旧：补图版本（既没有重构也没有标题改写）
11 分钟前  c861238  ← 新：审计修复 + 重构 + 标题（最全）
20 分钟前  ebd910f  ← 较新：重构 + 标题

根因清楚了：两个操作者从不同进度的本地检出各自执行部署。一个检出在最新提交上，另一个还停在”补图”提交。后部署的旧检出把前面所有成果都顶掉了。另外两个按 tag 触发的 CI 构建（2026.09.11-4/5）没有产出部署记录，疑似在流水线里构建失败——这也是为什么之前以为”打标签就会部署”的链路其实早就断了。

修复：从唯一的最新状态部署一次

1. git fetch 确认远端与本地差异，把所有已推送的成果合并到一条 main 上；
2. 从这条整合后的 main 执行一次 node deploy.cjs（构建 + wrangler pages deploy dist --branch main）；
3. 部署后 curl 核验：五个新分组、新标题全部在线。

三条规矩

1. 部署前先 git pull。本地检出落后远端时，一次部署就是一次回滚。
2. 部署命令统一走 deploy.cjs，并且它必须显式 --branch main——tag 触发的 CI 检出的是游离 HEAD，不带分支参数会被 Cloudflare 判成预览环境，白部署。
3. 一次只留一个部署入口的操作者。要么都走 CI，要么都走人工，混用就得约定”部署前互相打招呼”。

一个意外收获

排查时顺手验证了 wrangler pages deployment list 的排查价值：哪次部署、来自哪个 commit、什么环境、成功与否，一目了然。以后线上”没生效”类问题，第一动作就是拉这张表，比反复刷新页面猜快得多。

欢迎在评论区交流你的部署事故经历。