直接查看Network面板中index.html等资源的Status列：显示“(from disk cache)”表示强缓存生效；“304”表示协商缓存生效；“200”且无缓存标识则未命中缓存；再通过Response Headers确认Cache-Control等字段，并排查CDN、Service Worker等中间层覆盖问题。
怎么看浏览器到底有没有用缓存
打开开发者工具 → Network 面板 → 刷新页面，重点看 index.html 和关键资源（如 main.js、style.css）的 Status 列：如果是 200 且没有 (from memory cache) 或 (from disk cache)，说明没走缓存；如果是 304，说明走了协商缓存；如果是 200 + (from disk cache)，才表示强缓存生效。
右键对应请求 → Copy → Copy response headers，粘贴查看是否有 Cache-Control 或 Expires 字段。常见误判点：Cache-Control: no-cache 不等于“不缓存”，而是“每次用前必须验证”；max-age=0 同理。
为什么设置了 Cache-Control 却没生效
最常踩的坑是 CDN、反向代理或 Service Worker 覆盖了你服务器返回的响应头：
- Nginx 或 Cloudflare 等中间层可能对
/index.html应用了默认缓存规则（比如max-age=86400），压根没透传你后端设的no-cache - Service Worker 已注册且脚本里写了
event.respondWith(cache.match(event.request) || fetch(event.request))，但没做版本比对，直接返回旧缓存 - 本地开发时用
file://协议打开 HTML，浏览器根本不发 HTTP 请求，Cache-Control完全无效 - HTML 是 PHP/Node.js 动态生成的，但模板引擎或框架（如 Express 的
res.sendFile）默认加了缓存头，你没显式覆盖
怎么确认是 HTML 文件本身被缓存了
HTML 缓存失效影响最大——它决定了整个页面结构和资源引用路径是否更新。排查方法很直接：
立即学习“前端免费学习笔记（深入）”；
在 Network 面板里单独点击 index.html 请求 → 查看 Response 标签页里的原始 HTML 内容。如果看到的是旧的 <script src="app.js?v=1.2"></script>，而你刚部署的是 v=1.3，说明 HTML 文件根本没更新，问题出在服务端或 CDN 缓存上，不是前端构建的问题。
进一步验证：用 curl -I https://yoursite.com/ 检查响应头。如果返回 Cache-Control: public, max-age=31536000，那浏览器大概率会长期复用这个 HTML，哪怕 JS/CSS 已更新也无济于事。
构建工具输出的 HTML 为什么没带哈希或版本号
Webpack 的 html-webpack-plugin 默认不会自动给 <link> 或 <script> 标签注入哈希，除非你显式配置了 filename 或启用 hash: true 选项；Vite 在生产构建中默认启用内容哈希，但如果你手写 index.html 并用 <script type="module" src="/main.js"></script>，它就不会自动替换路径。
检查你的构建产物目录，确认 index.html 中引用的 JS/CSS 文件名是否含哈希（如 main.a1b2c3.js）。如果没有，即使你把 Cache-Control 设成一年，浏览器也会因为文件名不变而复用旧缓存，导致新逻辑永不生效。
真正卡住人的地方往往不在代码写得对不对，而在于你以为“缓存已禁用”，其实只是某一层（CDN、SW、Nginx location 块）悄悄把它又开了。每次怀疑缓存失效，先抓包看响应头，再逐层关掉中间件，比反复改代码快得多。
