手工验收的悖论：你知道哪些页面值得点开看，所以你每次都只看那些页面；而出问题的从来是另一些。把发布前走查写成脚本之后，它每天看的页面比人多，而且从不疲劳。
什么样的检查适合写进“运行时门禁”
单元测试证明函数正确，构建证明编译可行，但还有一类问题只有跑起来的站点才能回答：
- 每个 URL 是否返回预期状态（导航目标、sitemap 条目、索引里的 href）；
- 公开页面是否泄露内部词汇（工程术语、阶段状态、密钥样式的字符串）；
- 站内链接是否存在死链（渲染后的 HTML 里抽 href，逐个请求）；
- 核心接口冒烟（搜索索引 JSON 可读、Feed 合法、健康检查 200）。
这些检查的共同点：规则简单、覆盖面越大越值钱、人工执行必漏。
骨架：从枚举到断言
一个可复用的运行时门禁脚本大致四层：
// 1) 目标来源：sitemap + 页面内链 + 搜索索引 href，合并去重
const targets = collectFromSitemap();
targets.push(...extractHrefs(htmlOf('/'))); // 首页是最大入口分发器
for (const url of new Set(targets)) {
const res = await fetch(BASE + url, { redirect: 'manual' });
if (![200, 301, 302, 307].includes(res.status))
report.dead.push([url, res.status]);
}// 2) 禁用词扫描：公开路由的正文/标题/meta 命中即失败
const forbiddenTerms = [/MVP/i, /token/i, /内部阶段/, /staging 密钥/];
for (const route of publicRoutes) {
const html = await getHtml(route);
const hits = matchForbidden(html, { skipCode: true });
...
}// 3) 行为断言：关键路由必须含某些结构
expectHtml('/subscribe/status', /查询订阅处理结果/); // idle 态
expectHtml('/posts/', /文章/);
// 4) 产物一致性：索引条目的每个 href 都在站点可达集合内三个容易写歪的地方
其一：扫描范围里，“渲染后的 HTML”才算数。 直接读 public/*.json 或源码字符串会漏掉模板拼接出来的内容；起服务、发请求、解析响应体，才覆盖真实产物。本项目在 CI 与发布机各跑一次：CI 跑构建产物预览，发布机跑真实域名。
其二：禁用词扫描要有排除层，但不能有静默层。 命中 token 在代码块里是正常的（本文自己就出现过多次），所以扫描要跳过 <pre>/<code> 内容；但标题、摘要、导航文案命中即失败——这条曾经真实拦下过：新文章标题撞上了禁用术语，改的是文章，不是放宽规则。规则可以讨论粒度，不可以为了绿灯整体关闭。
其三：链接提取器要认识“活的 URL”。 现代页面里有大量 JS 注入的跳转（命令面板选项在插入 DOM 后才 setAttribute('href', …)），把脚本源码里的字面量当链接会误报死链。两种收敛方式：只提取渲染后 DOM 的 a[href]（需要真实浏览器），或者像本项目一样把注入写法改成“先插入后赋值”，让静态提取天然看不到占位符。
让门禁可复跑、可追溯
- 失败输出结构化：
{ deadLinks, publicCopyHits, routeFailures, pass }，一份 JSON 同时给人看和给 CI 断言； - 报告落盘并归档（
/tmp或 artifact 目录），复盘时能回答“当时到底绿没绿”； - 退出码诚实：任何 fail 都非零退出；环境缺依赖时明确打印阻塞原因，而不是
|| true吞掉。
边界：门禁不能替你判断的事
脚本回答“有没有死链/有没有违禁词/接口通不通”，不回答“这页好不好看、这篇文案有没有说服力”。视觉走查、内容审核、交互手感仍然是人的工作——自动化的意义恰恰是把机械部分压到零，让人的注意力只花在机器做不了的事上。
小结
把发布前走查写成四件套：枚举 URL → 探状态 → 扫词汇 → 验索引一致性。它拦不住所有问题，但它拦住的每一个，都是你“本来不会去点的那页”。