iframe跨域嵌入需对方服务端配合，否则浏览器静默拦截；必须校验origin并用postMessage通信，sandbox和allow属性须精确配置，fetch+innerHTML仅得静态快照。
iframe 的 src 属性必须是同源或明确允许的跨域资源
直接用 <iframe src="https://example.com"> 很可能空白或报错，不是 HTML5 不支持，而是目标站点设置了 X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none'。浏览器会静默拦截，控制台显示类似 Refused to display 'https://xxx' in a frame because it set 'X-Frame-Options' to 'DENY' 的错误。
解决前提是：你有权限协调对方站点——要么让其修改响应头，要么提供一个专用于嵌入的子路径（如 /embed），并配置 frame-ancestors 允许你的域名。
- 仅当对方明确支持嵌入时，
<iframe>才真正可行；否则前端无解 - 不要尝试用
document.domain或代理中转页面内容来绕过——前者已废弃，后者违反同源策略且易被识别为爬虫 - 若对方是 YouTube、Twitter、CodePen 等平台，优先用其官方提供的 embed 代码（含
allow属性和沙箱策略）
iframe 的 sandbox 和 allow 属性决定能力边界
即使目标页允许被嵌入，不加限制的 <iframe> 仍存在安全风险。HTML5 要求显式声明所需能力，否则默认禁用脚本、表单提交、弹窗等。
例如嵌入一个需调用摄像头的 WebRTC 页面，必须写：
<iframe src="https://trusted.example/call" sandbox="allow-scripts allow-media-elements allow-camera allow-microphone"></iframe>
立即学习“前端免费学习笔记（深入）”；
-
sandbox不带值 = 最严限制（连脚本都禁）；空字符串sandbox=""仍禁止插件、表单提交、弹窗等 -
allow后缀必须精确匹配规范关键词（如allow-popups≠allow-popup） - 涉及支付或敏感操作的第三方页，应避免使用
allow-scripts；可用postMessage做受控通信
用 postMessage 实现 iframe 与父页的安全通信
跨域 iframe 无法直接访问 window.contentWindow 或 document，但可通过 postMessage 传递结构化数据。这是 HTML5 唯一被广泛支持的跨域 iframe 通信机制。
父页发送消息示例：
const iframe = document.querySelector('iframe');<br>iframe.contentWindow.postMessage({ type: 'SET_THEME', value: 'dark' }, 'https://thirdparty.example');
子页监听示例：
window.addEventListener('message', (e) => {<br> if (e.origin !== 'https://thirdparty.example') return;<br> if (e.data.type === 'SET_THEME') { /* 处理 */ }<br>});
-
e.origin必须严格校验，不能只看e.source或用通配符*（除非你完全信任所有可能的来源） - 消息体应为纯 JSON 可序列化对象，避免传函数或 DOM 节点
- 父页监听需在 iframe 加载完成后绑定，否则可能丢失首次消息
替代方案：fetch + innerHTML 不等于“嵌入页面”
有人试图用 fetch 获取第三方 HTML 字符串，再用 innerHTML 插入到 <div> 中——这根本不是嵌入，只是渲染静态快照。所有脚本不会执行，样式可能冲突，表单无法提交，链接跳转失效，且大概率触发 CORS 错误。
- 这种做法对任何动态、交互型第三方页面都无效
- 即使绕过 CORS（如后端代理），也无法解决 Cookie 隔离、证书验证、混合内容（HTTP/HTTPS）等问题
- 唯一适用场景：你完全控制该第三方页，且它本身是纯静态、无 JS 依赖的展示页
真正的嵌入，永远绕不开对方的服务端配合和浏览器的 iframe 安全模型。别在客户端硬扛跨域限制。
