加时间戳参数是最简单有效的绕过 iframe 缓存方式，服务端配 cache-control: no-store 才算真正禁用；前端动态赋值 src + 后端响应头双管齐下才可靠。
iframe 页面不刷新，不是 HTML5 的锅，是浏览器把 src 当普通资源走 HTTP 缓存了——加时间戳最稳，服务端配 Cache-Control: no-store 才算真正禁用。
给 src 加时间戳参数是最简单有效的绕过方式
浏览器缓存判断依据是 URL 完全一致。只要让每次 src 值不同，就能强制发起新请求。
- 用
Date.now()，别用Math.random()：后者可能在单次渲染中多次调用，导致 iframe 重复加载或 src 变成多个不同值 - 避免拼太长的参数：URL 总长建议控制在 2048 字符内，
?v=1724644080123这种就够了 - 静态写死的
<iframe src="page.html"></iframe>永远不会自动更新，必须用 JS 动态赋值 - 示例：
<iframe id="my-frame"></iframe> <script> document.getElementById('my-frame').src = '/widget.html?v=' + Date.now(); </script>
Cache-Control: no-store 是服务端唯一靠谱的禁用方案
前端加参数只是“骗”浏览器发新请求，服务端不配合，旧响应仍可能被 CDN 或代理缓存住。
-
no-cache不够：它允许缓存，只是每次要用前得校验（可能返回304 Not Modified） -
must-revalidate要搭配no-store一起用，防止中间层忽略指令 - Nginx 配置示例：
location /widget.html { add_header Cache-Control "no-store, must-revalidate"; } - 务必用 DevTools → Network → 点开 iframe 请求 → 查看 Response Headers，确认头真的生效了
这些操作根本没用，别再试了
很多开发者踩坑后反复折腾，其实方向就错了。
-
meta http-equiv="Cache-Control"在 iframe 子页面里写无效：它只对作为顶层页面打开时起作用 -
location.reload(true)或history.replaceState()放在 iframe 内部执行，只刷新自己，清不掉父页对这个 URL 的缓存记录 - 手动 Ctrl+F5 或清空整个浏览器缓存：治标不治本，用户不可能每次都这么操作
- 只改 HTML 文件名但没同步更新所有引用点：容易漏，且不利于部署自动化
真正要落地，前端动态加参 + 服务端明确设 no-store 必须同时做；如果只能选一个，优先保证服务端响应头正确——否则就算你每次拼个 UUID，CDN 也可能直接返回缓存副本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
