HTML 绝对不能配 max-age，因为会导致用户在一小时内无法获取新版本，即使 JS/CSS 已更新也会因旧 HTML 请求不存在的资源而 404；应使用 no-cache 实现协商缓存，并确保服务端正确返回 ETag 或 Last-Modified，同时保障 CDN 和代理透传缓存头。
为什么 HTML 绝对不能配 max-age
HTML 是整个页面的入口，浏览器先加载它，再根据里面写的 script 和 link 标签去拉 JS/CSS。一旦你给 index.html 配了 Cache-Control: max-age=3600，用户接下来一小时内永远看不到新版本——哪怕你 JS 文件名带 hash、CDN 已刷新、服务端已重启，旧 HTML 仍会固执地请求 main.x9y8z7.js，结果是 404 或逻辑错乱。
这不是“缓存没刷新”，而是浏览器压根不发请求。你改了代码、重部署、清了 CDN，都没用。
-
no-cache是正确选择：它允许浏览器缓存 HTML 内容，但每次使用前必须发起协商请求（带If-None-Match或If-Modified-Since），由服务端决定返回304还是新 HTML - 别用
max-age=0替代：语义上它表示“立即过期”，行为接近no-cache，但部分老旧代理或中间件（如某些企业网关）可能忽略或错误处理它 - 警惕
Pragma: no-cache：这是 HTTP/1.0 的遗留头，若反向代理（如 Nginx）悄悄加了它，会直接覆盖Cache-Control，导致协商失效
如何让协商缓存真正生效（而不是每次都 200）
配了 no-cache 不等于协商就自动跑通。浏览器发协商请求后，服务端必须正确响应 ETag 或 Last-Modified，否则协商退化为“每次都 200”，白耗一次请求。
-
ETag必须基于文件内容生成（如sha256(fileContent)），不能用 inode 或本地修改时间——多实例部署时，不同机器返回不同ETag，协商必然失败 - 避免只用
Last-Modified：它精度只有秒级，同一秒内多次构建，时间戳不变，服务端可能误判“未更新”，返回304却给了旧 HTML - Nginx 默认对静态文件加
Last-Modified，但不会自动加ETag；需显式开启：etag on;，并确认未被add_header覆盖
CDN 和反向代理常吃掉你的缓存头
你本地测试 curl -I 看到 Cache-Control: no-cache，但用户浏览器 Network 面板里却显示 Cache-Control: public, max-age=86400——大概率是某一层中间件把你的头吞了、替换了。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- CDN 默认不透传自定义响应头，需在控制台或配置中显式开启 “Cache-Control 透传” 或 “自定义响应头透传”
- Nginx 反向代理若写了
expires off;或add_header Cache-Control "no-cache";，会直接覆盖上游（如 Vite/Next.js）返回的头 - Service Worker 若拦截了
index.html请求但没调用event.respondWith(fetch(event.request))，HTTP 缓存机制会被绕过，协商完全失效
静态资源（JS/CSS/图片）该用强缓存，但要配对 immutable
HTML 不能强缓存，但 JS/CSS/图片必须强缓存——前提是文件名含内容哈希（如 main.a1b2c3.js）。此时可放心设 Cache-Control: public, max-age=31536000, immutable。
-
immutable告诉浏览器：这个 URL 永远对应同一份内容，连刷新也不用走协商——省掉一次条件请求，真正实现“零请求复用” - 没加
immutable时，用户点刷新按钮，浏览器仍会发带If-None-Match的请求，哪怕你知道它 100% 返回304 - 如果构建产物没加 hash（比如 Webpack 仍输出
app.js），强缓存 +immutable就是灾难：用户永远卡在旧版本
最易被忽略的点：缓存策略不是单点配置，而是一条链——从构建输出命名、到服务端响应头、再到 CDN 和代理层透传，任一环断裂，HTML 更新就不可见。尤其当团队多人协作时，有人改了 Nginx 配置、有人开了 CDN 缓存、有人忘了关 Service Worker，问题就藏在这些交接缝隙里。
