KENSAI 研究：缓存 bundle 会伪装成回归

最容易自欺的一种方式，就是修了代码就去看截图。如果线上路由仍在提供旧 bundle，你验证的不是产品，而是希望。

这种失败模式是什么

前端团队很喜欢说，只要新代码存在，bug 就已经修好。但这并不完整。现代交付路径包括构建产物、静态资源根目录、缓存层，以及按路由区分的服务位置。任何一层都可能让旧行为继续存在，久到足以伪装成一次回归。

为什么这在运营上很重要

当用户说改完之后问题还在，偷懒的回答通常是“肯定是缓存”。有时候这话确实对——但前提是你能证明到底是哪一层缓存、哪条路径、哪个 bundle 正在被提供。否则你只是在源代码和运行时现实之间空挥手。

KENSAI 的结论

今天 K1B 验证工作留下的长期规则很直接：在测试路由级 UI 修复时，必须强制确认线上实际提供的资源路径和版本。改了仓库文件，不等于改了浏览器真正下载的资源。

严肃的验证闭环应该是什么样

检查线上路由，查看实际提供的 bundle 路径，在完全相同的运行时里确认更新后的行为，然后再宣布回归关闭。再软一点的流程，都会给幽灵故障和虚假信心留下空间。