把动态层拔掉，站还站得住吗

为什么要做这一步

概要设计里写了一条不变量：即使动态层全部宕机，网站（读）仍完整可用。 这句话很容易写成口号——因为默认情况下我们根本没配表单端点、没配统计脚本， 页面当然能打开，但那只是「碰巧没依赖」，不是「被验证过没有依赖」。

M5 的做法是反过来的：构建时故意把在线表单、预约外链、Umami 脚本全部指向一个不可达域名 （offline-dynamic.invalid），再用 Chrome 的 Network.setBlockedURLs 真正拦掉它们， 然后依次打开首页、作品列表、日志列表、作品详情、一条中文 slug 的日志详情。

实测结果

5 个页面全部有标题、有正文、有导航、图片没坏；首方资源零失败； 第三方脚本被拦了 7 次（blockedReason: "inspector"）。 也就是说：表单/预约/统计全断，读者依然能完整认识我、读到作品和创作记录。

一个比站点 bug 更值得记的教训

这个回归脚本第一次跑是 FAIL，但站点一行代码都不用改——坏的是测试自己：

• 探针环境变量漏了 PUBLIC_ 前缀，Vite 根本没把它们内联进产物，动态层压根没启用， 测试却准备宣称「拔掉动态层后一切正常」。这是最危险的一种假通过。
• 本地静态服务器没有模拟托管平台的 clean URL，详情页 404。
• 中文 slug 在 location.href 里被百分号编码，而传入的 URL 是 Unicode，等待条件永远不成立。
• 把「正文 > 200 字」当可读性下限，结果把本来就很短的作品列表页（162 字）判成坏页。

修完这 6 处，脚本才真正测到了它想测的东西。 「测试通过了」和「测试真的测了」之间，差的往往就是一次故意写坏的探针。 这与 M3 那次 reference() 探针是同一个道理，只是这次翻车的是测试代码本身。

还有一件没闭环的事

pnpm test:lead 证明了：订阅和联系表单会带着邮箱、同意、来源留痕被完整 POST 到端点， 浏览器能拿到回执，而且即使端点打不开，页面上仍留着邮件兜底链接。 但「作者真的收到邮件/通知」属于外部送达，得等部署时配上真实端点、人工提交一次才算数。 脚本不冒充这一步，规划书里也把它单列成了待办。