iframe加载失败本身不会导致崩溃，但错误容错逻辑（如无限重试、未清理定时器、onerror死循环）会快速耗尽内存或触发渲染阻塞，最终致页面卡死甚至标签页崩溃。
iframe 加载失败本身不会导致浏览器崩溃，但错误的容错逻辑（比如无限重试、未清理的定时器、onerror 死循环）会快速耗尽内存或触发渲染阻塞，最终让页面卡死甚至标签页崩溃。预防的关键不是“等它失败再救”，而是从设计上掐断失控链。
为什么 iframe.onerror + 重试会把页面搞崩
很多人一上来就写 onerror="this.src=this.src" 或在事件里反复赋值 iframe.src，结果是：备用地址也 404 → 再触发 onerror → 再赋值 → 无限递归。现代浏览器虽有栈深限制，但配合 setTimeout 轮询+没清 timer，几秒内就能生成上百个 pending 定时器，主线程彻底卡住。
- 同域下
iframe.onerror对 HTTP 404/500 不触发，写了等于白写，还可能干扰真实错误捕获 - 跨域 iframe 的
contentDocument和contentWindow直接为null，强行读取会抛DOMException，若没 try/catch 就中断后续逻辑 - 轮询检测若用
setInterval且忘记clearInterval，每次重试都叠加一个新轮询器，内存泄漏指数级增长
可靠 fallback 必须带「熔断」和「退避」
真正的容错不是“换一张图”，而是像电路保险丝一样，在异常累积到临界点前主动切断。对 iframe 来说，就是限制重试次数、拉长间隔、并明确标记状态。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 首次加载失败后，最多允许 2 次重试；第 3 次失败直接禁用重试按钮，显示「加载不可用」
- 重试间隔从 1s → 3s → 8s 递增，避免密集请求打垮服务端或触发 CDN 限流
- 每次重试前必须执行
iframe.src = ''清空，再设新值（加?t=Date.now()），否则 Chrome 可能复用旧响应 - 用
data-retry-count="0"存在 DOM 上，而不是靠闭包变量——防止多个 iframe 实例互相污染状态
检测逻辑必须早启动、早收口
别等 load 事件才开始检查。从 iframe.src 赋值那一刻起，就要启动超时探活；一旦确认失败，立刻停掉所有关联定时器，并释放对 contentDocument 的引用。
立即学习“前端免费学习笔记（深入）”；
- 赋值后立即调用检测函数：
startIframeHealthCheck(iframe, { timeout: 8000 }) - 检测函数内部用
setTimeout，而非setInterval；超时后只做一次判断，不轮询 - 判断依据只有两个硬指标：
!iframe.contentDocument（跨域） 或iframe.contentDocument?.body?.children.length === 0（静默白屏） - 一旦判定失败，立刻执行
clearTimeout(timerRef)，并移除所有绑定的load/error监听器
最常被忽略的是「退场清理」：fallback 区域显示后，原 iframe 的 DOM 节点还在内存里挂着，它的 contentWindow 可能仍在尝试解析或执行 JS。真要稳，就该在 fallback 触发时把 iframe remove() 或 replaceWith(div) —— 不是隐藏，是物理移除。
