postMessage是启用sandbox后唯一可用的通信通道，因iframe.contentWindow.document、parent等均失效，且仅postMessage被浏览器明确支持；必须监听load事件后调用，targetOrigin不可为'*'，子页须校验event.origin和event.data结构，Chrome 117+会丢弃非结构化数据。
postMessage 是唯一可用的通信通道
启用 sandbox 后，iframe.contentWindow.document、parent、window.top 全部为 null 或报错，eval() 和 Function 构造器也被拦截——浏览器明确只放行 postMessage。这不是“推荐做法”，而是硬性限制。
常见错误现象：iframe.contentWindow.postMessage(...) 报 TypeError: Cannot read property 'postMessage' of null，或消息发出去但子页收不到。
- 必须等
iframe触发load事件后再调用postMessage；setTimeout或 DOM 就绪判断不可靠 -
targetOrigin参数绝不能写'*'；生产环境必须精确匹配子页实际 origin（如'https://widget.example.com'） - 子页收到消息后，必须同时校验
event.origin和event.data结构（比如检查event.data.type === 'init'且event.data.nonce存在），仅用includes()匹配字符串是无效校验 - Chrome 117+ 会丢弃非结构化数据：传
new Date()、/regex/或函数，接收端得到的是undefined；只传 plain object
sandbox="allow-scripts" 不等于“JS 能随便跑”
加了 allow-scripts，外部 <script src> 和内联 <script> 可执行，但 HTML 内联事件处理器（onclick、onload）、javascript:void(0)、document.write() 全部静默失效，控制台不报错，行为直接被忽略。
典型表现：按钮点击无反应、<a href="javascript:..."> 点击后空白、动态写入 HTML 后事件绑定丢失。
立即学习“前端免费学习笔记（深入）”；
- 子页逻辑必须移入
<script>块或外部 JS，并用addEventListener绑定事件 -
allow-scripts无法恢复表单提交、弹窗、localStorage 访问能力；这些需额外加allow-forms、allow-popups、allow-same-origin - 动态设置
iframe.sandbox = "allow-scripts"无效；属性必须在appendChild前就写死 -
srcdoc内容同样受 sandbox 限制，哪怕没网络请求，内联事件也无效
allow-same-origin 是高危开关，不是信任开关
allow-same-origin 不是“我信它”，而是“它确实同源”的解锁凭证。浏览器加载时严格比对协议 + 域名 + 端口，三者不全等，该 token 直接被忽略，且不报任何警告。
常见陷阱：https://a.com 页面嵌入 https://b.com/widget.html 并加 allow-same-origin，结果 localStorage 仍不可读、fetch 同源请求照样被拦——因为根本没生效。
- 开发环境用
localhost:3000和localhost:80也不算同源（端口不同），allow-same-origin失效 - 即使同源，
allow-same-origin+allow-scripts也只恢复部分能力：DOM 访问仍受限，window.parent和document依然不可访问 - 第三方内容绝对不要加
allow-same-origin；敏感操作（如登录态同步）必须附带签名或一次性 token，不能只靠 origin 校验
iframe 生命周期必须手动管理
SPA 中 iframe 不随路由卸载，useEffect 或 beforeDestroy 不会触发其内部 JS 清理。子应用的定时器、WebSocket、全局 message 监听器持续运行，造成内存泄漏和状态错乱。
典型症状：路由跳转后，子应用仍在后台轮询、弹窗出现在旧 iframe 区域、多次进入同一页面导致重复监听。
- 销毁前必须显式调用
iframe.contentWindow?.close()，再remove()DOM 节点 - 不要复用
contentWindow；每次加载新子应用都应新建iframe实例；about:blank是唯一能保证初始干净的起点 - 若子应用有 cleanup 逻辑，销毁前需先
postMessage通知其执行自身清理 -
load事件不代表 JS 执行完毕；动态import()、window.onload绑定的代码可能尚未运行，初始化消息不能紧随load发送
allow-scripts 和 allow-same-origin 的组合使用，以及 postMessage 中非结构化数据的 silently drop 行为——这两处既不报错，又不抛异常，问题只在特定环境或用户操作路径中暴露。 
