HTML不应长期缓存，须设no-cache或max-age=0,must-revalidate以确保及时更新；静态资源需文件名哈希+immutable实现长期缓存，且CDN策略须与源站响应头一致。
HTML本身不直接“缓存”，真正起作用的是浏览器对HTML及其引用资源（如CSS、JS、图片）的缓存行为。优化多文件页面加载，关键不是让HTML缓存得更久，而是让它“不阻碍更新”——同时确保它引用的静态资源能被长期、安全地缓存。
为什么不能长期缓存 HTML 文件
HTML 文件通常包含动态内容或指向其他资源的路径（比如 <script src="app.12345.js">）。如果 HTML 被强缓存（如 Cache-Control: public, max-age=3600），用户可能一直用着旧版 HTML，即使 JS/CSS 已更新，也无法触发新资源加载。
- 现象：改了 JS 逻辑，但用户刷新后仍执行旧代码
- 根本原因：浏览器没发请求，直接用了本地缓存的 HTML，里面仍引用旧 hash 文件名或旧 URL
- 正确做法：HTML 缓存时间设短（如 5 分钟），或禁用强缓存（
no-cache），靠协商缓存（ETag/Last-Modified）判断是否更新 - Nginx 示例：
location = /index.html { expires 5m; add_header Cache-Control "no-cache"; }
让 CSS/JS/图片等静态资源长期缓存的关键：文件名哈希化
HTML 不缓存太久，但它的“子资源”必须缓存足够久——前提是它们的 URL 能随内容变化而变化。否则浏览器无法感知更新。
- 错误方式：
<script src="app.js">→ 改了 app.js，但 URL 没变，浏览器继续用旧缓存 - 正确方式：
<script src="app.a1b2c3.js">→ 构建时自动注入内容哈希，内容一变，URL 就变，浏览器视为全新资源 - Webpack 用户：启用
output.filename: "[name].[contenthash].js"，配合html-webpack-plugin自动注入带 hash 的 script 标签 - 无构建工具？可用版本号参数（不推荐）：
app.js?v=2.1.0—— 但需手动维护，且部分 CDN 可能忽略 query 参数
Cache-Control 配置要区分资源类型
同一份配置套用所有资源会出问题。HTML、API 接口、字体、图片、JS/CSS 各自的更新频率和风险不同，缓存策略必须差异化。
立即学习“前端免费学习笔记（深入）”；
- HTML：
Cache-Control: no-cache, must-revalidate（强制协商）或max-age=300（5 分钟） - CSS/JS：
Cache-Control: public, max-age=31536000, immutable（1 年 + immutable 表示永不变更，可跳过协商） - 字体（woff2）：
public, max-age=31536000，但避免immutable（某些浏览器对字体支持不佳） - API 响应（JSON）：
no-store或no-cache，尤其含用户数据时 - 注意：
immutable是 HTTP/1.1 扩展指令，IE 完全不支持，Chrome/Firefox/Edge 支持良好
容易被忽略的细节：ETag 和 Last-Modified 的协同失效
当 HTML 设置了 no-cache，浏览器每次都会发请求验证，但若服务器没返回 ETag 或 Last-Modified，就只能返回完整 HTML，失去协商缓存价值。
- 现象：HTML 缓存设为
no-cache，但每次请求都收到 200 + 完整 body，而不是 304 - 原因：Nginx/Apache 默认可能不生成 ETag；或你用了反向代理（如 Cloudflare），它覆盖/清除了源站响应头
- 检查方法：curl -I https://yoursite.com/index.html，看是否有
ETag或Last-Modified - 修复建议：Nginx 中开启
etag on;；Apache 启用FileETag；CDN 后台确认未剥离这些头
最复杂的点不在怎么设 max-age，而在于 HTML 和它引用的资源之间那层脆弱的信任关系——HTML 是“指挥官”，但它自己不能太固执；资源是“士兵”，必须自带身份标识（hash）才能被放心长期驻守。漏掉任意一环，缓存就从加速器变成陷阱。
