iframe会阻塞window.onload，导致页面假死；必须动态设置src或用loading="lazy"延迟加载，禁用sandbox则等同于向第三方开放主站dom；其seo差、可访问性弱、内存开销大，应优先考虑api渲染、web components等替代方案。
不好——除非你明确需要它的隔离性，且已接受它带来的性能、安全和可访问性代价。
iframe 会阻塞 window.onload，页面右上角转圈停不下来
浏览器必须等所有 iframe 及其内部资源（HTML、JS、图片、字体）全部加载并执行完，才触发主页面的 onload。哪怕某个 iframe 因网络抖动或第三方服务宕机卡住，整个页面就“假死”在 loading 状态。
- 真实表现：
document.readyState长时间停留在interactive，用户感知为“页面打不开” - 修复方式：不要在初始 HTML 里写死
src，改用 JS 动态创建并插入，时机选在DOMContentLoaded后 - 更稳妥补丁：加上
loading="lazy"（Chrome 76+ 支持），让浏览器自动延迟非视口内 iframe 的加载
不加 sandbox 的 iframe = 把主站 DOM 白送给第三方
默认情况下，iframe 拥有完整执行权限：能运行脚本、读写同源 localStorage、调用 alert、提交表单、甚至尝试 top.location.href = 'https://evil.com' 劫持整个页面。
- 最小可用配置：
sandbox="allow-scripts"—— 允许 JS 执行，但禁用 DOM 访问、弹窗、表单提交 - 跨域通信时才加
allow-same-origin，且必须配合postMessage使用，不能只靠它开权限 -
sandbox=""（空值）最严格：连脚本都不允许运行，适合嵌 PDF 或纯静态内容
SEO 和屏幕阅读器基本“看不见” iframe 里的内容
Google 官方明确表示：搜索引擎不会执行 iframe 内的 JS，也不会索引其 HTML（除非该 URL 被单独抓取）。屏幕阅读器对 iframe 支持极弱，尤其缺少 title 属性时，用户完全不知道里面是什么。
-
title属性不可省，例如：<iframe title="用户评论模块"></iframe> - 别用
iframe承载核心业务内容（如商品描述、文章正文）；必须嵌入时，提供<noscript></noscript>或语义一致的<div> 备用文案 <li>移动端尤其敏感：低端 Android 设备容易因内存压力触发 iframe 卸载或白屏</li> <h3>每个 iframe 都是独立渲染进程，内存翻倍不是夸张</h3> <p>Chromium 架构下，每个 <code>iframe都启动一个完整的渲染进程；即使在轻量级引擎中，也至少分配独立的 JS 引擎上下文。DevTools 的 Memory 面板里，Document和JSHeap条目清晰可见。- 实测数据：3 个 iframe 常使内存占用比纯单页高 30%~50%
- 连接池消耗：每个 iframe 的域名都占用浏览器并发连接数（现代浏览器通常限 6 个/域），多个跨域 iframe 会挤占主页面关键资源的加载通道
- 替代思路优先级：API + 客户端渲染 > Web Components > 服务器端包含（SSI/SSR）>
iframe
真正难的不是怎么写
iframe标签，而是判断“这个需求是否真的绕不开它”。一旦用了，就得为它的每一个生命周期、每一次跨域通信、每一份额外内存负责。
