单纯靠标签无法可靠禁止缓存，因其仅为浏览器提示而非强制指令，现代主流浏览器基本忽略；真正有效的是服务端响应头cache-control: no-store, no-cache, must-revalidate, max-age=0等设置。
单纯靠 <meta http-equiv> 标签无法可靠禁止浏览器缓存，尤其是跳转页、刷新后退、CDN 或静态资源场景下基本失效。
为什么 <meta http-equiv="Cache-Control"> 经常没用
浏览器只在 HTML 文档首次加载时读取这些 <meta> 标签，且现代浏览器（Chrome 124+、Firefox 125+、Safari 17+）对它们的解析越来越宽松——它只是“提示”，不是强制指令。更关键的是：
- 跳转后的页面（如
window.location.href = "page.html"）是否缓存，由目标页的 HTTP 响应头决定，跟源页面的<meta>无关 - 用户点「返回」按钮看到的 stale 页面，大概率是 bfcache（back/forward cache），和 HTTP 缓存无关，
<meta>完全不参与控制 - JS/CSS/图片等资源走的是独立请求，它们的缓存行为由各自响应头控制，HTML 里的
<meta>对它们零影响 -
<meta http-equiv="Pragma">在所有主流浏览器中被完全忽略，W3C 规范也未要求支持
<meta http-equiv="Cache-Control"> 的正确写法与限制
如果必须用前端方式临时补救（比如托管在 GitHub Pages、Netlify 等无法改服务端头的环境），只保留这一行，其他都删掉：
<meta http-equiv="Cache-Control" content="no-store">
注意以下要点：
-
no-store是唯一真正阻止缓存存储的指令；no-cache允许缓存但强制验证，实际仍可能走协商缓存（ETag/Last-Modified） - 大小写敏感：
cache-control小写在旧 IE 中可能不识别，必须写成Cache-Control（首字母大写） - 不要混用
max-age=0和no-store：前者仍允许缓存，后者直接禁止存储，语义冲突 - 该标签必须放在
内，且不能有 JS 或服务器端输出提前触发文档流
跳转页面仍被缓存？前端能做的只有 URL 扰动
当无法修改服务端响应头（例如跳转到第三方页面或纯静态 HTML），唯一可控的方式是让 URL 变得唯一：
- 用时间戳参数：
window.location.href = "page.html?t=" + Date.now() - 避免
location.replace()：它不产生历史记录，但也不绕过缓存，和href走同一套缓存逻辑 - 慎用随机数：
Math.random()在单页内多次调用可能生成相同值，Date.now()更可靠 - 这个方法只对「跳转发起方」有效，目标页本身仍需服务端头配合，否则刷新后依然可能缓存
最常被忽略的一点：即使你在 HTML 里写满了 <meta>，只要服务端返回的响应头里是 Cache-Control: public, max-age=3600，浏览器就按响应头执行——<meta> 不会覆盖它。禁缓存这件事，终究是服务端的责任。
