iframe间通信不会发生传统死锁，因其js线程隔离、无共享内存、消息纯异步投递，不满足互斥、占有并等待、不可剥夺、循环等待四条件；所谓“卡死”实为消息积压、端口未调用start()、监听未就绪或主线程被同步操作阻塞所致。
不存在传统意义上的死锁，所谓“卡死”是消息积压、端口未激活或同步阻塞导致的假性停滞。
为什么 iframe 间调用不会发生死锁
死锁需要互斥、占有并等待、不可剥夺、循环等待四个条件同时成立。而 iframe 的 JS 执行环境完全隔离，window 对象不共享内存，postMessage 和 MessageChannel 都是纯异步投递机制，没有锁、没有资源抢占——你看到的“卡住”，其实是某一方没监听、消息被静默丢弃、或主线程被同步操作堵死。
- 父页在
onmessage回调里执行了耗时 DOM 操作（比如渲染万行表格），后续消息事件无法及时调度 - 子 iframe 尚未绑定
port2.onmessage就收到父页发来的消息，该消息直接丢失（规范行为，非 bug） - A → B → A 循环触发消息，且每轮都未加节流，快速压垮事件循环
高频通信下 MessageChannel 端口必须显式 start()
MessageChannel 的两个 port 默认处于关闭状态，不调用 port.start() 就无法接收消息。嵌套 iframe 场景中，若 A 创建 channel 后把 port2 发给 B，B 必须在收到后立即调用 port2.start() 并绑定 onmessage，否则所有发往该 port 的消息都会被丢弃。
- 错误写法：
port2.onmessage = handler;但漏掉port2.start(); - 正确顺序：先
port2.start()，再赋值onmessage；或用addEventListener('message', handler)+port2.start() - 特别注意：iframe 的
load事件完成 ≠port已就绪，需确保脚本执行时机晚于 port 传递完成
嵌套 iframe 通信必须严格分层，禁止端口复用
父页 → A → B 是三层结构，每条链路必须独占一对 MessageChannel 实例。不能让 A 把父页传来的 port2 直接转手给 B，也不能让 A 和 B 共享同一对 port —— 这会导致消息路由错乱、监听冲突、甚至 port 被意外 close()。
- 父页创建
channel1，将channel1.port2发给 A；A 收到后调用channel1.port2.start() - A 自己创建
channel2，将channel2.port2发给 B；B 收到后调用channel2.port2.start() - B 的响应必须经由 A 中转回父页，不能绕过 A 直连父页
- 每个 iframe 只持有自己收发用的 port，其他 port 不应出现在其作用域中
同源 iframe 直接调用方法时的常见阻塞点
同源下可通过 iframe.contentWindow.xxx() 或 parent.window.xxx() 直接调用，但极易因时机错配引发“未响应”：iframe 尚未加载完成，父页就尝试调用其方法；或子页调用父页方法时，父页函数内部执行了同步长任务。
- 务必监听
iframe.onload，且在回调中才访问contentWindow；避免仅靠DOMContentLoaded判断 - 若子页需调用父页方法，建议父页暴露的函数为异步封装（如返回
Promise），避免同步阻塞 - 动态设置
iframe.src后，不要立刻读取contentWindow—— 应等load触发后再操作 - 本地开发时用
file://协议会触发伪跨域，即使同目录也报错，改用本地 server（如python -m http.server）
真正麻烦的从来不是“能不能通”，而是“什么时候通、谁先准备好、消息有没有被悄悄吃掉”。端口生命周期、事件监听时机、调用链路拓扑，三者缺一不可。稍有错位，就表现为页面卡死，但 debugger 里却找不到任何报错。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
