HTML缓存由HTTP响应头控制，meta标签基本无效；应通过Nginx等配置no-cache+ETag实现HTML协商缓存，JS/CSS则用hash化+immutable强缓存。
HTML5 页面本身不决定缓存行为，真正控制缓存的是 HTTP 响应头和 Cache-Control、Expires 等字段；直接在 HTML 源码里写 几乎无效（尤其对 HTML 文档自身），别被误导。
为什么
浏览器加载 HTML 时，会优先信任服务器返回的 HTTP 响应头，完全忽略 这类标签。这个标签只在极少数离线场景（如本地双击打开 file://）下可能起作用，但生产环境毫无意义。
- HTTP 响应头由 Web 服务器（Nginx/Apache）、CDN 或后端框架（如 Express、Django）控制，不是前端 HTML 能改的
-
标签无法影响 HTML 主文档的缓存，但对部分内嵌资源（如通过加载的页面）可能有微弱影响，不可依赖 - Chrome、Firefox 等现代浏览器明确将
视为“仅用于向后兼容”，不用于主文档缓存决策
Nginx 中正确配置 HTML 缓存策略
HTML 文件通常需要「不缓存」或「短缓存 + ETag/Last-Modified 验证」，避免用户看到旧版本页面。关键不是设 max-age 多大，而是配合校验机制。
location ~* \.html$ {
# 强制每次检查服务端是否更新（不缓存 HTML 本身）
add_header Cache-Control "no-cache, must-revalidate, max-age=0";
# 同时提供校验依据，让浏览器发条件请求
add_header ETag "";
# 可选：启用 Last-Modified（需后端支持）
# add_header Last-Modified $date_gmt;
expires epoch;
}-
no-cache不代表“不存”，而是“每次用前必须验证”，浏览器仍可缓存 HTML，但会带If-None-Match或If-Modified-Since请求头去问服务器 -
expires epoch是 Nginx 写法，等价于Expires: Thu, 01 Jan 1970 00:00:01 GMT，强制过期时间已到 - 不要对 HTML 设
public, max-age=3600—— 用户改了页面，CDN 或代理可能一直吐旧 HTML，连刷新都不管用
如何验证 HTML 缓存策略是否生效
打开 Chrome DevTools → Network 标签页 → 刷新页面 → 找到 index.html 请求 → 查看 Headers → Response Headers 区域。
立即学习“前端免费学习笔记（深入）”；
- 如果看到
Cache-Control: no-cache, must-revalidate, max-age=0和Expires: Thu, 01 Jan 1970 00:00:01 GMT，说明配置已生效 - 再看
Status列：首次是200，第二次是304（Not Modified）→ 表明浏览器走了协商缓存，策略起效 - 如果第二次仍是
200且响应体完整返回，说明没走缓存或服务端没返回ETag/Last-Modified，需检查 Nginx 是否启用了add_header ETag ""或后端是否生成校验值
JS/CSS/图片该用什么缓存策略
这些静态资源适合强缓存，但必须解决「更新后用户不拉新文件」的问题。核心是「文件内容哈希化」+ 「HTML 中引用带 hash 的路径」。
- 构建工具（Webpack/Vite）输出
main.a1b2c3d4.js，内容变则 hash 变，文件名就变 - Nginx 对这类带 hash 的静态资源配长缓存：
add_header Cache-Control "public, max-age=31536000, immutable"; -
immutable告诉浏览器：这个 URL 永远不会变内容，不用再发条件请求（节省一次往返） - 注意：
immutable仅在 HTTPS 下有效，且不能用于 HTML —— 因为 HTML 总是动态的
最容易被忽略的一点：HTML 文件本身的缓存策略必须和它引用的 JS/CSS 资源解耦。哪怕 JS 已缓存一年，只要 HTML 更新了引用路径，用户就能拿到新逻辑；反过来，如果 HTML 被错误地长期缓存，用户永远看不到新 JS 的入口，所有优化都白搭。
