加时间戳参数是最简单有效的前端手段，但仅绕过缓存而非禁用；真正禁用需服务端返回cache-control: no-store，且http响应头优先级高于meta标签。
直接加时间戳参数是最可靠、最可控的解法，服务端不配合也能立刻生效；但仅靠它只是“绕过”缓存，不是“禁用”缓存——如果 iframe 页面被其他地方复用（比如独立访问、被别人嵌入），仍可能被缓存。
给 src 加时间戳是最简单有效的前端手段
浏览器对 iframe 的缓存判断完全基于 URL 字符串是否一致。只要每次 src 不同，就不会命中缓存。
- 用
Date.now()生成毫秒级时间戳，比Math.random()更稳妥：避免同一页面多次渲染时重复加载或生成重复值 - 不要拼在静态 HTML 里，必须动态设置——否则首次加载后 HTML 就固定了，后续刷新无效
- 示例写法：
<iframe id="my-frame"></iframe> <script> document.getElementById('my-frame').src = '/widget.html?v=' + Date.now(); </script> - URL 总长度别超 2048 字符，尤其当路径本身很长或带多参数时，避免拼接过多无意义字段
服务端必须返回 Cache-Control: no-store 才算真正禁用缓存
前端加参数只是骗浏览器“这是新请求”，但若服务端响应头允许缓存，这个资源仍可能被 CDN、代理或浏览器存下来供下次复用。
-
no-cache不够：它允许缓存，只是强制校验（可能返回 304），对 iframe 无效 -
no-store是硬性指令：禁止任何环节存储响应体，包括内存和磁盘 - Nginx 配置示例：
location /widget.html { add_header Cache-Control "no-store, must-revalidate"; } - 务必用 DevTools → Network → 点开 iframe 请求 → 查看 Response Headers，确认
Cache-Control确实生效且值含no-store
<meta http-equiv> 在 iframe 子页里基本没用
很多人在 iframe 指向的 HTML 文件里写 <meta http-equiv="Cache-Control" content="no-cache">，但这只影响该 HTML 作为顶层页面打开时的行为，对被嵌入为 iframe 的场景完全无效。
- HTTP 响应头优先级远高于
<meta>标签，浏览器根本不读 iframe 子页里的这些 meta - IE 甚至会忽略子页中所有 cache 相关 meta（历史兼容问题）
- 真正要控制 iframe 内容缓存，必须从服务端响应头或父页面的
src构造入手
注意 iframe 自身重载不会清父页面缓存
有人在 iframe 子页里写 location.reload(true) 或 history.replaceState()，指望它能“刷新整个嵌入链”，这是误解。
- 这些操作只作用于 iframe 当前文档，不影响父页面，更不会让父页面重新请求 iframe 的
src - 父页面一旦加载完成，它的 DOM 和资源就固定了；iframe 内部刷新只是子文档生命周期事件
- 如需触发父页面重新加载 iframe，只能由父页面主动改写
iframe.src，或用iframe.contentWindow.location.reload()（仅同源）
真正麻烦的是跨域 iframe：你既不能改它的响应头，也不能用 JS 控制其内部 reload，唯一能动的只有父页面拼 src 参数——所以时间戳方案虽土，却是跨域场景下唯一通用解法。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
