iframe是唯一原生支持跨域隔离的嵌入方案，因其创建独立浏览上下文，能安全加载第三方页面；其他方式无法真正隔离或受同源策略限制。
iframe 是目前网页中嵌入第三方页面最直接、兼容性最好、且唯一原生支持跨域隔离的方案。其他方式（如 object、JavaScript 动态插入 HTML 片段）要么受限于同源策略，要么无法真正隔离上下文，不适用于第三方页面。
为什么必须用 iframe 嵌第三方页面
第三方页面通常部署在不同域名下，浏览器的同源策略会阻止脚本读取其 DOM、监听其事件或修改其样式。只有 iframe 能在保持安全隔离的前提下，加载并渲染跨域内容。它创建的是一个独立的浏览上下文（browsing context），有自己的 window、document 和事件循环。
常见错误是试图用 fetch + innerHTML 加载第三方 HTML——这会失败，因为跨域请求被 CORS 拦截；即使代理绕过，嵌入的内容也会失去 JS 执行环境、相对路径失效、Cookie 不携带，实质上已不是“第三方页面”，而是被撕碎重组的静态片段。
iframe 的基础写法与关键属性
最简可用写法：
<iframe src="https://example.com/login"></iframe>
但生产环境必须补全以下几项：
-
src必须是完整协议 URL（https://或http://），本地file://协议下多数浏览器会拒绝加载第三方页面 -
width和height推荐显式设置，否则默认尺寸极小（约 300×150px），且部分浏览器对百分比宽高支持不稳定 -
sandbox属性必须加，尤其嵌入不可信来源时。最小安全集：sandbox="allow-scripts allow-same-origin"；若不需要 JS 执行，去掉allow-scripts；若明确要跨域通信，才加allow-same-origin（注意：加了该值后，同源检查将失效，需自行承担风险） -
referrerpolicy="no-referrer"可选，防止第三方通过document.referrer获取你页面的路径信息 -
title属性建议加上，提升可访问性（屏幕阅读器会读出）
嵌入后无法交互？检查这三点
常见现象：页面能显示，但按钮点不动、表单提交无响应、滚动条卡死。
- 目标页面设置了
X-Frame-Options: DENY或Content-Security-Policy: frame-ancestors 'none'—— 这是服务端主动拒绝被嵌入，前端无法绕过，只能联系对方修改响应头 - 父页面 CSS 泄漏影响 iframe 内容，比如全局
* { box-sizing: border-box; }可能破坏子页面布局；解决方案：给iframe外层容器加overflow: hidden，并在 iframe 上加style="border: none;"防止默认边框干扰 - 移动端 Safari 对
iframe的scrolling属性完全忽略（该属性 HTML5 已废弃），如需禁用滚动，必须在子页面内部用 CSS 控制：body { overflow: hidden; }
跨域通信不能只靠 window.postMessage
如果需要和第三方页面交换数据（比如登录成功后通知父页），postMessage 是唯一标准方案，但容易漏掉关键细节：
- 发送方必须指定
targetOrigin（不能写"*"，尤其涉及敏感操作时），例如：iframe.contentWindow.postMessage(data, "https://example.com") - 接收方必须校验
event.origin，否则可能收到伪造消息：if (event.origin !== "https://example.com") return; - 第三方页面若未主动监听
message事件，你的postMessage就是单向石沉大海；需提前约定好通信协议，或通过iframe.onload触发初始化握手 - 不要依赖
iframe.contentDocument或iframe.contentWindow直接访问——跨域下它们是null或抛错
真正复杂的嵌入场景（如微前端、多租户控制台），iframe 的隔离性反而是优势，但它的加载延迟、内存开销、SEO 不友好等代价也真实存在。别为了“看起来像一个页面”而强行隐藏 iframe 边界，先确认业务是否真的需要跨域执行权——很多时候，用户只需要看到那个页面，而不是控制它。
