跨域 iframe 通信唯一合法路径是 postmessage + 严格校验；chrome 126+ 已彻底禁用 document.domain，sandbox="allow-same-origin" 对跨域 src 无效，且 contentwindow 访问被浏览器硬性拦截。
跨域 iframe 通信没有“配置属性”能绕过同源策略，唯一合法路径是 postMessage + 严格校验；所有试图用 sandbox、allow 或 document.domain 实现直接 DOM 访问的方案，在 Chrome 126+ 及现代浏览器中均已失效。
为什么不能直接访问跨域 iframe 的 contentWindow
浏览器硬性拦截，不是 bug 也不是配置疏漏。当你写 iframe.contentWindow.document 或 iframe.contentDocument，控制台立刻报错：Blocked a frame with origin "https://a.com" from accessing a cross-origin frame。这不是开发环境特例——生产环境一样拦，且无法通过服务端响应头或 HTML 属性解除。
常见误判场景：
- 以为加了
sandbox="allow-same-origin"就能当同源用 → 实际需子页与父页协议、域名、端口完全一致，且该 sandbox 权限仅在子页由 same-origin URL 加载时才生效（即不能是跨域 src） - 在本地开发用
http://localhost:3000和http://localhost:8080测试，误以为“没报错=能通” → 这俩仍是不同源，只是某些旧版浏览器未严格执行，新版已统一拦截 - 尝试设
document.domain = "example.com"→ Chrome 126+ 已彻底移除该 API，调用即报TypeError: Cannot set property document.domain
postMessage 发送端必须等 load 事件再调用
iframe.contentWindow 在 iframe 未加载完成时为 null，此时调 postMessage 不报错但消息静默丢失——这是最常被忽略的“无感失败”。
正确做法：
- 监听
iframe.onload，而非依赖 DOM ready 或定时器 - 若 iframe 是动态插入的，确保在
appendChild后立即绑定onload，不要等后续逻辑 - 发送时第二个参数
targetOrigin必须精确：用https://child.example.com，而不是'*'或'https://*.example.com'；测试环境也应写死为http://localhost:3000（非'*'）
示例：
const iframe = document.getElementById('my-iframe');
iframe.onload = () => {
// 此时 contentWindow 才可靠
iframe.contentWindow.postMessage({ type: 'INIT', data: {} }, 'https://child.example.com');
};
接收端必须校验 event.origin，不能只看 event.data
event.origin 是浏览器注入的、不可伪造的来源标识；而 event.data 完全由发送方控制，可被恶意 iframe 任意构造。
危险写法（等同于不校验）：
-
if (event.data.from === 'trusted-app')→ 字段可伪造 -
if (event.origin.includes('example.com'))→ 攻击者注册evil-example.com即可绕过 -
if (event.origin === location.origin)→ 子页发来的 origin 永远≠父页 origin（跨域前提下）
安全写法：
if (event.origin !== 'https://child.example.com') return;- 若需支持多源，用白名单数组严格比对：
['https://child1.example.com', 'https://child2.example.com'].includes(event.origin) - 收到消息后，如需调用父页方法，仍要二次确认权限（例如检查
event.data.type是否在预设枚举内）
sandbox 和 allow 的组合极易放大风险
sandbox 不是“开了就安全”，而是“配错比不加更危险”。默认空值（sandbox=""）禁用脚本、表单、插件等全部能力；但开发者常误开权限：
-
sandbox="allow-scripts allow-same-origin"→ 若子页内容不可控（如嵌第三方广告），等于赋予其父页同源权限，可读 Cookie、调用父页 API -
allow="geolocation microphone camera"→ 浏览器会在 iframe 加载时立即弹出权限请求，用户未操作前就暴露敏感能力意图，且可能被滥用 -
allow="clipboard-read clipboard-write"→ 第三方 iframe 可静默读写剪贴板，属高危权限，除非明确需要，否则禁用
真正最小化写法示例：
<iframe src="https://child.example.com" sandbox="allow-scripts" allow="fullscreen" referrerpolicy="no-referrer"> </iframe>
注意：allow="fullscreen" 已替代废弃的 allowfullscreen 属性；referrerpolicy 防止子页获知父页完整 URL。
复杂点在于：通信链路越长（比如父页 → iframe A → iframe B），每层 postMessage 的 targetOrigin 和 event.origin 校验都必须独立、精确。漏一层，整个信任链就崩了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
