检测iframe加载超时需轮询contentdocument?.readystate或fallback至contentwindow?.document?.readystate，8–10秒未变complete/interactive即判失败；重试须先置src=''再赋值，记录data-retry-count限3次，指数退避（0s/2s/4s），非同源仅能超时+手动重试。
iframe加载超时怎么检测
浏览器不提供原生的 iframe 超时事件，onerror 对 iframe 完全无效，load 事件又会在空白页、500 错误页甚至 200 HTML 报错页下照样触发——它只表示“请求结束了”，不表示“内容可用了”。真正能落地的判断依据只有两个：iframe.contentDocument?.readyState 和 iframe.contentWindow?.document?.readyState。
这两个值在加载开始时为 "loading"，成功或失败后会变成 "complete" 或 "interactive"；但如果页面根本没回来（404/500/网络中断），它们可能一直卡在 "loading"，或直接是 null（尤其 Safari 下 contentDocument 常为 null）。
- 必须加超时保护：设 8–10 秒计时器，超时即判为失败
- 检查要早：在
iframe.src赋值后立刻启动轮询，别等load事件 - 读取顺序要对：优先用
contentDocument，fallback 到contentWindow?.document - 补充验证：即使
readyState === 'complete'，也要检查body.children.length === 0，防空白页误判
怎么写自动重试逻辑
重试不是简单地再赋一次 src，否则部分浏览器（如旧版 Chrome）会复用缓存响应，甚至不发新请求。关键动作是先清空再赋值，并控制重试次数和退避间隔。
- 重试前务必设
iframe.src = ''，再赋原地址，强制刷新加载流程 - 用
data-retry-count记录当前重试次数，避免无限循环（建议上限 3 次） - 第二次起用指数退避：第一次立即重试，第二次等 2 秒，第三次等 4 秒
- 非同源 iframe 无法读取
contentDocument，此时只能靠超时 + 用户点击按钮重试，别硬塞 JS 判断
为什么不能用 location.reload() 或 innerHTML 替换
iframe.contentWindow.location.reload(true) 看似直接，但它只对同源 iframe 有效，且 reload 会继承当前 document 的状态（比如表单已填数据），可能触发浏览器“重新加载页面？”提示框；而用 innerHTML = '<iframe src="...">'</iframe> 替换整个节点，虽能绕过提示，但会丢失绑定的事件监听器、Observer 实例和已有 DOM 引用。
- 动态创建新 iframe 是更干净的做法：用
document.createElement('iframe')，复制data-src、sandbox、title等关键属性，再插入原位 - 旧 iframe 移除前，记得调用
observer.unobserve()或clearTimeout()清理资源 - 若 iframe 用于广告或分析埋点，重试后需手动调用 SDK 的
refresh()或display()方法，否则不计费也不展示
实际部署要注意的兼容性坑
loading="lazy" 在首屏 iframe 上基本无效，它会被浏览器强制 eager 加载并阻塞 DOM 解析；而 IntersectionObserver 在 Safari 15.3 及更早、IE、多数安卓 WebView 中不支持，且父容器用了 transform 或 overflow: hidden 也会让懒加载失效。
- 不要依赖
loading="lazy"来解决超时问题，它和超时检测无关 - 微信 iOS 内置浏览器、QQ 浏览器等仍可能忽略
loading属性，回退为 eager 行为 - 如果 iframe src 含
?t=时间戳或Math.random()，缓存失效会导致每次都是“新请求”，超时概率翻倍 - 服务端响应头必须含
Cache-Control: public, max-age=3600，禁用no-cache和no-store
clearTimeout 和 removeEventListener 必须配对出现，否则会造成内存泄漏，尤其在 SPA 页面频繁切换 tab 时。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
