iframe本质是独立文档容器而非布局框架，会阻塞onload、存在安全与seo风险，需慎用sandbox、title等属性并避免嵌套。
iframe 不是“框架嵌套”的推荐方案，它本质是独立文档容器，不是传统意义上的页面布局框架。现代项目里直接用多个 iframe 嵌套（比如 iframe 里再放 iframe）会快速放大所有固有缺陷，不建议这么做。
为什么 iframe 会阻塞 window.onload
浏览器必须等所有 iframe 及其内部资源（HTML、JS、图片、字体）全部加载并执行完毕，才触发主页面的 onload 事件。哪怕某个 iframe 加载缓慢或失败，整个页面都会卡在“加载中”状态。
- 真实现象：页面右上角转圈一直不消失，
document.readyState长时间停留在interactive - 修复方式：用 JavaScript 动态创建
iframe，并在DOMContentLoaded后插入，避免初始 HTML 中写死src - 更稳妥做法：搭配
loading="lazy"属性（Chrome 76+ 支持），让浏览器自动延迟非视口内iframe的加载
sandbox 属性不是可选，而是默认安全底线
不加 sandbox 的 iframe 相当于把一个完整网页的执行权限白送给第三方——它能运行脚本、提交表单、弹窗、访问 localStorage（同源时），甚至尝试 top.location.href 跳转劫持。
- 最小可用配置：
sandbox="allow-scripts"—— 允许执行 JS，但禁用 DOM 访问、表单提交、弹窗等 - 需要跨域通信时才加
allow-same-origin，且必须配合postMessage使用，不能只靠它开权限 -
sandbox=""（空值）最严格：连脚本都不允许运行，适合仅展示静态内容（如 PDF）
SEO 和可访问性不是“可能受影响”，而是基本不可见
Google 官方明确表示：搜索引擎不会执行 iframe 内的 JS，也不会索引其 HTML 内容（除非该 URL 被单独抓取）。屏幕阅读器对 iframe 的支持也极弱，尤其缺少 title 或 aria-label 时，用户完全不知道里面是什么。
- 补救动作必须显式做：
title属性不可省，例如<iframe title="用户评论模块"></iframe> - 不要依赖
iframe承载核心业务内容（如商品描述、文章正文） - 如果必须嵌入关键内容，提供
<noscript></noscript>或<div> 备用文案，并确保与 iframe 内容语义一致 <h3>性能损耗不是理论值，而是可测量的内存翻倍</h3> <p>每个 <code>iframe都启动一个完整的渲染进程（Chromium 架构下）或至少一个独立的 JS 引擎上下文。DevTools 的 Memory 面板里，iframe对应的Document和JSHeap条目清晰可见。3 个iframe常使内存占用比纯单页高 30%~50%。- 移动端尤其敏感：低端 Android 设备容易因内存压力触发 iframe 卸载或白屏
- 避免“为了复用”而滥用：用 CSS + JS 实现的头部/侧边栏复用，远比用
iframe加载同一份 HTML 更轻量 - 动态销毁策略：用
IntersectionObserver监听离开视口后，主动remove()iframe 元素，而非仅display: none
iframe标签，而是判断“这里到底该不该用”。它的隔离性是双刃剑——你得到安全和解耦，代价是失去控制、可观测性和性能确定性。
