本质是不同资源绕过不同版本缓存导致逻辑错配；需检查HTML中资源链接版本是否统一、构建后HTML是否注入最新哈希、服务端文件内容是否更新、多层缓存是否残留旧资源、CI/CD部署是否完整覆盖。
绕过缓存后页面 JS/CSS 版本不一致，本质不是“缓存没绕过”，而是“不同资源绕过了不同版本的缓存”，导致样式、脚本、HTML 三者之间出现逻辑错配。常见表现是：按钮点击无反应（JS 未加载新逻辑）、页面布局错乱（CSS 是新版但 JS 还在操作旧 DOM 结构）、或控制台报 undefined is not a function（JS 新增了方法但 CSS 里 class 名已改）。
检查 HTML 中静态资源链接是否统一更新
手动加 ?v=xxx 时最容易出问题：只改了 CSS 的版本号，忘了同步 JS 或 HTML 模板里的引用；或者构建后部分文件没重命名，而 HTML 里仍指向旧哈希名。
- 打开浏览器开发者工具（F12），切换到 Network 标签页，刷新页面
- 筛选
css和js，逐个查看每个资源的请求 URL，确认它们的版本标识（如v=2.4.0或.abc123.js）是否一致且符合本次发布预期 - 特别注意：如果用了构建工具（Vite/Webpack），检查生成的 HTML 是否真的被自动注入了最新哈希——不要只看本地
index.html，要看部署后线上实际返回的 HTML 源码（右键 → 查看网页源代码）
验证服务端是否真正返回了新文件内容
URL 变了，不代表文件内容就新。有时 CDN 缓存了旧响应体，或 Nginx 配置了 alias 但没 reload，导致 app.a1b2c3.js 实际仍指向旧文件。
- 复制任一 JS/CSS 的完整 URL（例如
https://yoursite.com/static/app.a1b2c3.js），在新标签页中直接打开 - 查看响应内容是否包含你本次修改的代码片段（比如新增的函数名、注释、CSS 类名）
- 用
curl -I检查响应头：ETag或Last-Modified是否与你本地构建产物一致；若 ETag 长期不变，说明服务端文件可能没更新
排查多层缓存是否残留旧资源
即使你在 HTML 里写了 ?v=20260917，CDN、反向代理、甚至 Service Worker 仍可能把旧版本资源缓存在更上游位置，造成“URL 新、内容旧”的假象。
立即学习“前端免费学习笔记（深入）”；
- 检查 CDN 控制台（如 Cloudflare、EdgeOne）是否对
.js/.css路径设置了强制长缓存，且未配置“忽略查询参数”或“缓存键排除v=” - 若使用 Service Worker，打开 Application → Service Workers，勾选 “Update on reload”，然后刷新；再检查
cache.keys()是否还存有旧版本资源（可在 Console 执行） - 对关键资源发起带随机参数的请求测试，如
main.css?t=123456，观察是否返回新内容——若仍旧，说明问题不在浏览器，而在中间层
确认构建与部署流程未引入版本漂移
CI/CD 中常见陷阱：打包机生成了新哈希文件，但上传脚本漏传某个 chunk；或灰度发布时，HTML 走 A 服务器（新），而 JS/CSS 走 B 服务器（旧）。
- 比对构建产物目录中的文件名哈希，和线上实际可访问的资源路径是否一一对应
- 检查部署日志，确认所有静态资源（尤其是
assets/下的 JS/CSS）都成功上传且覆盖到位 - 如果是多实例部署，用
curl -H "Host: yoursite.com" http://ip-of-instance/static/app.js分别请求各节点，确认内容一致
