微信里打开的 H5 页面仍执行旧 JavaScript，先确认客户端拿到了哪一个文件。旧项目中，电脑刷新能看到更新，手机仍保留旧行为；退出再登录后恢复。但这个结果只能说明当时状态发生了变化，不能单独证明缓存究竟位于微信、浏览器还是中间节点。

对比行为之前，先对比资源

一次部署可能同时经过 HTML、静态资源服务器、CDN 和客户端缓存。HTML 如果仍引用旧文件，即使 JavaScript 文件服务器已经更新，页面行为也不会随之改变。

可沿请求链检查：

  1. HTML 中引用的脚本 URL 是否属于本次构建。
  2. 实际响应内容或文件摘要是否与部署产物一致。
  3. Cache-Control、ETag、Last-Modified、Age 等响应信息。
  4. 请求是否返回 304，以及是否使用了预期的缓存版本。
  5. 页面若有 Service Worker，是否还存在另一层缓存与更新策略。

这些是排查入口，不是每个旧项目都使用了全部组件。304 表示复用验证后的已有表示，不等于“服务器根本没收到请求”。HTTP 缓存说明

用构建版本区分资源

例如生成带内容摘要的文件名：

<script src="/assets/app.a1b2c3.js" defer></script>

这里文件名仅作结构示意，必须与真实构建产物对应。内容更新时产生新 URL，HTML 随部署引用新文件；不能只在页面上改一个版本号，却没有发布相应资源。

通常可以对内容寻址的静态资源安排较长缓存，对入口 HTML 安排能及时检查更新的策略。具体缓存头应结合部署方式决定，不要直接对所有路径套同一个长 max-age。

刷新不是唯一的修复目标

用户退出微信、清理全部数据或反复刷新，只适合有限的对照观察，不应成为每次版本发布的使用说明。更稳妥的结果是：新入口能引用一致版本，旧页面能在合理时机更新，失败时也不会拿到一半新一半旧的资源。

如果现象只涉及支付后返回页状态，应优先重新读取业务状态，而不是全站清缓存，见支付后返回页面。资源版本与订单状态属于不同问题。