iframe是仅在内容与主站不同源且不可控、又必须当前页渲染时才应使用的嵌套方案，典型场景包括第三方支付弹窗、YouTube视频嵌入及政府办事窗口；误用于同源页面或纯数据加载反而损害性能与可访问性。
iframe 不是“能用就用”，而是“该用才用”。绝大多数页面嵌入需求，第一反应不该是 iframe，而是先问：能不能用 fetch + innerHTML？能不能用 Web Components？能不能走后端聚合？只有明确满足特定边界条件时，iframe 才是合理解。
什么时候必须用 iframe？
核心判断依据就一条：内容与主站**不同源且不可控**，同时又**必须在当前页渲染**。
- 第三方支付/认证弹窗（如支付宝收银台、微信登录页）——你无法改它的 JS，也不能把它拉到自己域名下
- 嵌入 YouTube 视频或 Google Maps —— 官方只提供
iframe片段，不开放 DOM 访问或跨域 API - 客户要求嵌入某政府平台的办事窗口（如社保查询页），且该平台明确拒绝同源请求或 CORS 配置
- 需要隔离执行环境：比如在编辑器里预览用户写的 HTML/CSS/JS，必须防止恶意脚本污染主页面
注意：srcdoc 属性虽支持内联 HTML，但它生成的文档默认同源，不适用于“规避跨域”场景；它适合的是可控的、轻量的嵌入（比如帮助文档片段），而非对接外部系统。
iframe 的常见误用场景
这些情况用 iframe 反而增加复杂度、损害可访问性与 SEO：
- 嵌入自己同一域名下的静态页面（如
/about.html）——直接用fetch+insertAdjacentHTML更轻量，还能复用主页面样式和状态 - 加载纯数据接口（如 JSON）——
iframe无法读取响应体，只能靠 URL 参数或 postMessage 间接通信，绕远路 - 做“伪单页应用”路由（用
iframe切换不同子页面）——失去浏览器前进/后退、URL 同步、history API 控制能力 - 为“兼容老系统”硬套
iframe而不做适配——结果是滚动条嵌套、焦点管理失效、屏幕阅读器无法穿透
src、srcdoc 和动态 document.write 的选择差异
三者能力与限制完全不同，不能混用：
立即学习“前端免费学习笔记（深入）”；
-
src：加载远程资源，天然跨域隔离；但无法传参（除非拼 query），无法拦截加载过程，错误时仅触发load或error事件 -
srcdoc：内容写死在 HTML 中，同源，可含内联 script/style；但长度受限（某些浏览器对 base64 或字符串长度有隐式限制），且无法加载外部 CSS/JS 文件 - 动态
document.write（通过contentWindow.document）：仅限同源 iframe，且必须在load后立即调用，否则会清空整个文档；现代开发中基本被弃用，易出竞态
例如想嵌入一段带按钮的提示框：srcdoc 最合适；想接入银行支付页：src 是唯一选择；想在 iframe 里运行用户上传的 HTML 并调试？得加 sandbox="allow-scripts"，但禁止 allow-same-origin，否则等于主动开后门。
容易被忽略的安全与可访问性硬约束
上线前漏掉这几项，可能直接导致合规风险或功能不可用：
- 必须加
title属性——不是可选，是 WCAG 2.1 AA 强制要求，否则屏幕阅读器无法告知用户“这是什么内容的窗口” - 跨域
iframe默认无法被contentDocument访问，若需通信，双方都得调用window.postMessage，且必须校验event.origin，不能写成"*" -
sandbox属性不设值（即sandbox=""）等于禁用所有能力；若要执行 JS，至少得显式写sandbox="allow-scripts"；若要表单提交，还得加allow-forms - 移动端 Safari 对
iframe的height:100%支持不稳定，建议用min-height+ JS 监听resize动态调整，或改用 CSS Grid/Flex 布局兜底
真正难的不是怎么写 <iframe src="..."></iframe>，而是判断这个 src 是否真的不该由你自己的服务代理一次，以及那个“第三方”是否悄悄改了 CSP 头导致你的 postMessage 被静默丢弃。
