meta标签的http-equiv="cache-control"在现代浏览器中完全无效，缓存行为仅由服务器响应头决定；仅content-type、refresh等少数http-equiv值仍有效，且与缓存无关。
Meta 标签的 http-equiv="Cache-Control" 在现代浏览器中完全无效，不能用于可靠控制 HTML 页面缓存。 你看到的缓存行为，100% 由服务器返回的 HTTP 响应头（如 Cache-Control、Expires）决定，和 <meta> 无关。
为什么 http-equiv="Cache-Control" 实际不起作用
这不是写法问题，而是浏览器设计层面的取舍：
- Chrome、Firefox、Safari 自 2010 年代起已移除对
http-equiv缓存指令的解析逻辑，仅保留对Content-Type、Refresh等少数值的支持 -
http-equiv本质是“模拟”响应头，但真实响应头具有绝对优先级；只要服务端返回了Cache-Control: public, max-age=3600，哪怕你在里写了十行no-cache，浏览器也只认服务端那个 - 本地用
file://协议打开 HTML 时，根本不存在 HTTP 头，此时http-equiv更是彻底不被解析——但这常被误当作“它本来能工作” - DevTools Network 面板里看到的
Status: 200 from disk cache或Cache-Control值，全部来自服务器响应头，不是<meta>
哪些 http-equiv 值还“勉强可用”
不是所有 http-equiv 都废了，但能用的非常有限，且用途和缓存无关：
-
Content-Type：仍有效，用于声明字符集，如<meta http-equiv="Content-Type" content="text/html; charset=utf-8">。注意拼写必须是charset，不是encoding -
Refresh：可触发页面跳转或重载，如<meta http-equiv="Refresh" content="3;url=/thank-you.html">。但它不参与缓存控制，且对无障碍和 SEO 不友好，建议优先用 JS 或服务端重定向 -
Content-Security-Policy：部分浏览器支持，用于设置 CSP 策略，和缓存无关 -
X-UA-Compatible：仅 IE 有效，现代项目基本不用 -
Pragma和Expires：已被主流浏览器忽略，W3C 规范也不再推荐
当服务端无法配置时，前端能做的“补救”手段
如果你托管在 GitHub Pages、Netlify、Vercel（未配 _headers）等静态平台，确实没法改服务端头——此时 <meta> 仍是无效的，但你可以绕过缓存机制本身：
- 对跳转链接加时间戳扰动：
window.location.href = "page.html?t=" + Date.now()。注意别用Math.random()，单页内多次调用可能重复 - 对资源引用（JS/CSS）做内容哈希，比如
main.a1b2c3.js，这样 HTML 更新后，新 URL 自然绕过旧缓存 - 强制刷新时禁用缓存：用户按
Ctrl+Shift+R（硬刷新）会跳过强缓存，但这不是你能控制的用户体验 - 如果必须用
<meta>做心理安慰（比如客户坚持要加），只留一行：<meta http-equiv="Cache-Control" content="no-store">。注意：no-store是唯一有实际阻止存储效果的指令，no-cache允许缓存，只是强制校验
真正容易被忽略的是：HTML 缓存策略和 JS/CSS 必须分开设计。HTML 应禁用强缓存（靠服务端设 no-cache 或 max-age=0），而 JS/CSS 可放心用 max-age=31536000 + 内容哈希——混为一谈是多数缓存问题的根源。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
