必须禁用强缓存、启用协商缓存：因html是spa入口，强缓存会导致浏览器一小时内不发请求，旧html引用更新后的哈希资源引发404或逻辑错乱；no-cache允许缓存但强制每次校验，配合内容哈希etag和cdn/代理透传才能确保304协商生效。
针对单页面应用（SPA）的 index.html，必须禁用强缓存、确保协商缓存稳定生效——这不是“可选优化”，而是避免白屏、404 和逻辑错乱的底线策略。
为什么强缓存对 index.html 是危险的
HTML 是整个页面的入口。一旦浏览器强缓存了它，后续一小时内（哪怕你配了 max-age=3600）就再也不会发起请求。此时即使 JS/CSS 已更新并带 hash，旧 HTML 仍会固执地加载不存在的 main.a1b2c3.js，直接触发 404 或执行旧逻辑。清 CDN、重启服务、强制刷新都无效，因为请求压根没发出去。
- no-store 虽然彻底禁用缓存，但牺牲首屏速度（每次都要完整下载 HTML）
- max-age=0 行为接近协商，但部分老旧代理可能误处理
- no-cache 是唯一推荐方案：允许浏览器暂存内容，但每次使用前必须发协商请求
让协商缓存真正起效的关键配置
只写 Cache-Control: no-cache 不够。浏览器发了 If-None-Match 或 If-Modified-Since，服务端必须能正确比对并返回 304，否则协商退化为“每次都 200”，白白多一次请求。
Comet AI 浏览器
下载
下载 Comet AI 浏览器，体验由 Perplexity AI 驱动的革命性上网方式。内置 AI 助手可实时总结网页、跨标签页对比信息、自动执行任务。告别繁琐操作，让 AI 成为你的浏览副驾，大幅提升研究与工作效率。支持 Windows、macOS、Android 和 iOS。
- ETag 必须基于文件内容生成（如
sha256(fileContent)），不能用 inode 或修改时间——多实例部署时，不同机器返回不同 ETag 会导致协商失败 - Last-Modified 精度只有秒级，同一秒内多次构建，时间戳不变，可能误判为“未更新”而返回 304
- Nginx 需显式开启
etag on;，且确认未被add_header覆盖；默认只加 Last-Modified，不加 ETag
服务端精确匹配与头透传防护
缓存策略必须由服务端响应头控制，<meta http-equiv> 在所有现代浏览器中已被完全忽略（自 2018 年起），写再多也无效。
- Nginx 中必须用
location = /index.html精确匹配，避免location /index.html波及带查询参数或备份文件的路径 - CDN 和反向代理常吃掉你的缓存头：本地
curl -I看到no-cache，但浏览器 Network 面板显示public, max-age=86400，大概率是某层中间件覆盖或丢弃了头 - 需在 CDN 控制台开启“Cache-Control 透传”，Nginx 反向代理中避免使用
expires off或全局add_header Cache-Control，否则会覆盖上游框架（如 Vite/Next.js）的正确设置
验证是否真正生效的三步法
别靠地址栏回车或 F5 判断——它们可能走内存缓存或强制校验，结果不可靠。
- 打开 DevTools → Network → 点击 index.html 请求 → 查看 Response Headers 是否含
Cache-Control: no-cache（且无其他覆盖项） - 刷新页面后观察该请求状态码：应为
304（协商命中）或200（内容更新），而非200 (from memory cache) - 修改 index.html 内容并重新部署，再次刷新：应收到新内容（200），而非继续用旧缓存
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
