单纯靠<meta http-equiv>标签无法可靠禁止浏览器缓存，现代浏览器（Chrome 124+、Firefox 125+、Safari 17+）在HTTP(S)场景下基本忽略它，因缓存行为由服务端响应头决定，<meta>仅是提示且无法覆盖实际响应头。
单纯靠 <meta http-equiv> 标签无法可靠禁止浏览器缓存，现代浏览器（Chrome 124+、Firefox 125+、Safari 17+）在 HTTP(S) 场景下基本忽略它——它不是指令，只是提示，且只在极少数边缘场景“看起来有效”。
为什么 <meta http-equiv="Cache-Control"> 经常没反应
浏览器的缓存行为由服务端返回的响应头（如 Cache-Control、Expires）决定，<meta> 不参与 HTTP 协议，也无法覆盖或修改实际响应头。只要服务器返回了任何 Cache-Control 值（哪怕只是 public, max-age=3600），所有主流浏览器都会直接跳过解析 <meta http-equiv>。
- 你在
<head>里写满no-store、must-revalidate，DevTools Network 面板里依然看不到对应响应头 - 状态码显示
200 from memory cache或304，说明缓存已生效，<meta>完全未起作用 -
<meta http-equiv="Pragma">在所有现代浏览器中被完全忽略，W3C 规范也未要求支持 - 跳转后的页面（如
window.location.href = "page.html"）是否缓存，取决于目标页的响应头，和源页面的<meta>无关
哪些场景下 <meta> 可能“看似有效”（但不可依赖）
这些情况容易误导开发者，误以为 <meta> 有用，实则与真实线上环境脱节：
- 本地双击打开 HTML 文件（
file://协议）：无服务端响应头，部分浏览器会参考<meta>，但这不是 Web 场景 - 老旧 IE6–8（已淘汰）：对
Pragma和Expires有松散支持，但行为不一致、不可测 - 某些定制 WebView（如旧版 Cordova、Electron 特定配置）：底层引擎未严格遵循标准，属例外
一旦部署到 Nginx/Apache/Node.js 等真实服务端，这些“有效”立刻消失。
立即学习“前端免费学习笔记（深入）”；
如果必须用 <meta>（例如 GitHub Pages、Netlify 无法改服务端头）
仅保留这一行，其他全删：
<meta http-equiv="Cache-Control" content="no-store">
注意要点：
-
no-store是唯一真正阻止缓存存储的指令；no-cache允许缓存，只强制验证，仍可能走协商缓存（ETag/Last-Modified） - 大小写敏感：
Cache-Control必须首字母大写，cache-control在旧 IE 中可能不识别 - 不要混用
max-age=0和no-store：前者仍允许缓存副本，后者禁止存储，语义冲突 - 该标签必须放在
<head>内，且不能有 JS 或服务端输出提前触发文档流（否则可能被忽略）
跳转页面仍被缓存？前端唯一可控方式是 URL 扰动
当无法控制目标页的服务端响应头（比如跳转到第三方页面或纯静态托管页），<meta> 完全无效，只能让 URL 变得唯一：
- 用时间戳参数：
window.location.href = "page.html?t=" + Date.now() - 避免
location.replace()：它不产生历史记录，但也不绕过缓存，和href走同一套缓存逻辑 - 慎用
Math.random()：单页内多次调用可能生成相同值；Date.now()更可靠
这个方法只对跳转发起方有效，目标页本身仍需服务端头配合，否则用户刷新后依然加载缓存版本。
最常被忽略的一点：即使你在 HTML 里写满了 <meta>，只要服务端返回的响应头里没设置 Cache-Control: no-store，浏览器就按默认策略缓存——这不是前端能补救的事。
