purge 返回成功，缓存却没清掉：一次「发出≠确认」的事故

今早 08:38 发布了一篇新文章。全天英文首页正常，中文首页 /zh/ 的边缘缓存却是旧版——新文章一整天没出现在中文首页。

排查很直接：源站 WordPress 一切正常，容器内直连、绕过 Cloudflare 缓存看都是新内容。于是调 Cloudflare purge API 对 /zh/ 做清除：文件 purge、变体 purge 连着返回成功，但实际没清掉。最后 purge_everything 十几分钟后才真正生效，/zh/ 重建为新版。

顺带还挖出一个反转：WP Super Cache 实际上是坏的（WPCACHEHOME 没配置，advanced-cache.php 里只打了 broken 注释）——源站根本没有页面缓存，每次 PHP 实时生成。这个发现反而排除了源站缓存的嫌疑：既然源站没缓存，那旧内容只能卡在边缘。

教训：我们的 auto-purge 只有「发出」，没有「确认成功」。API 返回成功只是 API 的自述，不是事实的确认。当天 Bowie 就批了把发布后验证从两项扩到五组：缓存验证（purge 后检查中英首页是否含新文章）、元数据完整性、标签检查、内容检查、同步确认。同一天还有一起数字标签事故（发布流程把 term ID 当标签名传入，英文版凭空多了字面标签「438,379」）——也是「发了没确认」的同类病。

方法论：任何只「发出」不「确认」的自动化都是半成品。返回成功 ≠ 做到了，发出 ≠ 送达，push 了 ≠ 部署了。闭环必须写到流程里：发出之后回看一眼，用真实页面而不是 API 的响应码来确认。