HTML文件本身不适合长期缓存，应设no-cache或max-age=0,must-revalidate确保每次验证更新；静态资源则需配合内容哈希与immutable指令实现强缓存，CDN策略必须与源站响应头一致，否则易导致版本错配。
HTML 文件本身不适合长期缓存，盲目设 max-age 会导致用户看到过期内容；真正能提速的是把 HTML 当作“索引”，让 CSS/JS/图片等静态资源走强缓存，同时确保 HTML 自身能及时更新。
为什么直接给 index.html 设 max-age=3600 很危险
HTML 通常含动态内容：用户昵称、未读数、CSRF token、时间戳——哪怕只改一个字，旧缓存就会导致功能异常或数据错乱。常见现象包括：
- 登录后仍显示“请登录”按钮
- 商品价格没变，但下单时发现已涨价
- 表单提交失败，因为隐藏字段里的
csrf_token已失效
根本原因是 max-age 触发强缓存，跳过服务器验证；而 HTML 很少配 ETag 或 Last-Modified 做兜底，浏览器就真的一小时都不问服务器了。
HTML 应该用 no-cache 还是 max-age=0？
两者效果接近，但语义和协作行为不同：
立即学习“前端免费学习笔记（深入）”；
-
Cache-Control: no-cache表示“可缓存，但每次必须验证”——浏览器会带If-None-Match或If-Modified-Since发请求，服务端返回304 Not Modified就复用本地副本 -
Cache-Control: max-age=0, must-revalidate是更明确的写法，强制每次走协商流程，兼容性略好于纯no-cache - 别用
private：CDN 节点会忽略它，若你依赖 CDN 加速，资源就无法被边缘缓存 - 绝对不要用
<meta http-equiv="Cache-Control" content="...">：现代 Chrome/Firefox/Edge 完全忽略它，只在某些老旧 WebView 中降级生效
真实生效的方式只有两种：Nginx 配置 add_header Cache-Control "no-cache"，或后端代码（如 Express）调用 res.set('Cache-Control', 'no-cache')。
静态资源怎么配才真正减少请求
提速的关键不在 HTML，而在它引用的 CSS/JS/img——这些文件体积大、变动少，适合激进缓存：
- 必须用构建工具生成带内容哈希的文件名，例如
main.a1b2c3.js，内容一变 URL 就变，浏览器自然弃旧取新 - Nginx 配置示例：
location ~* \.(css|js|woff2|png|jpg|gif)$ { expires 1y; add_header Cache-Control "public, immutable"; } -
immutable指令很重要：它告诉浏览器“这个 URL 永远不会变内容”，后续访问可跳过If-None-Match验证请求，省掉一次往返 - 如果不用哈希命名，
immutable反而危险——改了文件内容但 URL 不变，用户就永远拿不到新版本
CDN 缓存和源站响应头不一致怎么办
这是最常被忽略的协同断点：你 Nginx 设了 no-cache，但 CDN 后台默认开启“自动缓存 HTML”，结果用户刷新看到的还是 10 分钟前的首页。
- 检查 DevTools → Network → 点开
index.html请求 → 看响应头中Cache-Control是否为你设的值，再看x-cache（Cloudflare）或x-cdn-cache（阿里云）确认是否命中 CDN - 登录 CDN 控制台，找到 HTML 路径（如
/index.html），显式设置为“遵循源站响应头”或手动覆盖为Cache-Control: no-cache - 对带哈希的静态资源路径（如
/static/main.*.js），CDN 也应设为Cache-Control: public, immutable，避免中间层覆盖源站策略
缓存不是单点设置，而是链路配合；一个环节断掉，前面所有配置都白搭——尤其当 HTML 引用的 JS 路径没做哈希，而你又给 HTML 配了长缓存时，错配风险最高。
