iframe 缓存问题源于 HTTP 缓存机制，非 HTML5 特性；解决方法首选前端加时间戳参数（如?v=ts），或服务端设置 Cache-Control: no-store；CDN/代理层缓存需同步配置。
HTML5 iframe 嵌入页被强缓存，刷新不生效
浏览器对 iframe 的 src URL 会像普通资源一样走 HTTP 缓存逻辑——哪怕页面本身加了 Cache-Control: no-cache，只要服务端响应头没明确禁止缓存（或返回了 304 Not Modified），iframe 内容就可能复用旧版本。
常见现象：主页面更新了，但嵌入的 iframe 仍显示旧 HTML/CSS/JS；开发者工具 Network 面板里看到状态是 from disk cache 或 from memory cache；手动 Ctrl+F5 有时也不管用。
- 根本原因不是 HTML5 特性，而是 HTTP 缓存机制对
iframesrc 的默认处理 - 服务端未设置
Cache-Control: no-store或max-age=0时，浏览器可自由缓存 -
meta http-equiv="Cache-Control"在 iframe 子页面中无效——它只影响该文档作为顶层页面时的行为
给 iframe src 加时间戳参数（最简落地方案）
在生成 iframe 标签时，动态拼接一个无意义但变化的查询参数，强制打破 URL 缓存。这是前端可控、无需服务端配合的最快解法。
示例（JavaScript 动态插入）：
立即学习“前端免费学习笔记（深入）”；
- 避免用
Math.random()：可能导致同一页面内多次渲染时 iframe 重复加载 - 若需支持「局部刷新 iframe 而不重载整个页面」，可封装成函数，每次调用都更新
src - 注意：URL 长度限制（通常 2048 字符），不要拼太长的参数串
服务端响应头必须设为 no-store 才真正禁用 iframe 缓存
仅靠前端加参数是“绕过”缓存，而非“清除”缓存。要让 iframe 每次都走真实请求，服务端需明确告知浏览器：这个资源不准存。
关键响应头（以 Nginx 为例）：
add_header Cache-Control "no-store, must-revalidate";
-
no-store是硬性要求：禁止浏览器磁盘/内存缓存该响应体 -
must-revalidate补充语义，防止中间代理（如 CDN）擅自忽略缓存指令 - 不要只写
no-cache：它允许缓存，只是每次要用前必须校验（仍可能返回304） - 检查实际响应头是否生效：打开 DevTools → Network → 点开 iframe 请求 → 查看 Headers → Response Headers
iframe 页面自身调用 location.reload(true) 无法清空父级缓存
有人尝试在 iframe 子页面里写 location.reload(true) 或 history.replaceState()，但这只影响 iframe 自身文档的重新加载，对父页面中该 iframe 元素的 src 缓存记录毫无作用。
- 父页面一旦解析并请求过某个
srcURL，其缓存键（cache key）就已建立；子页面 reload 不会触发父页面重新发起网络请求 - 跨域 iframe 更受限：父页面无法读取或操作子页面 DOM 和 history，连 reload 都可能被拒绝
- 真正需要刷新的是父页面如何发起 iframe 请求，而不是子页面怎么“自救”
最易被忽略的一点：CDN 或反向代理（如 Nginx proxy_cache、Cloudflare）可能在服务端层就缓存了 iframe 的响应，此时即使浏览器请求带了时间戳，也可能被代理直接返回旧内容——务必确认缓存控制策略在整条链路上都生效。
