postMessage传大文件卡顿失败的根本原因是未使用Transferable对象导致结构化克隆开销；应通过transfer数组移交ArrayBuffer所有权实现零拷贝，且必须分片、序号校验、逐片ack确认，并避免跨iframe中转。
postMessage 传大文件会卡顿甚至失败？
直接用 postMessage 发送 ArrayBuffer、Blob 或 base64 字符串，浏览器会做完整结构化克隆（structured clone），对 >10MB 的数据极易触发主线程阻塞、内存溢出或静默丢弃。Chrome 限制单次消息 payload 约 16MB（实际更低），Safari 更严。这不是“传输慢”，而是根本不可靠。
用 Transferable 对象绕过拷贝开销
真正高效的方式是传递可转移对象（Transferable），让底层内存所有权直接移交，零拷贝。但注意：只有 ArrayBuffer、MessagePort、ImageBitmap 等少数类型支持 transfer，Blob 不行，base64 字符串更不行。
- 发送方必须显式传入
transfer数组，例如：iframe.contentWindow.postMessage(arrayBuffer, 'https://target.com', [arrayBuffer]) - 传完后原
arrayBuffer变成detached，不能再读 —— 这是安全机制，不是 bug - 接收方在
event.data中拿到的是同一块内存的引用，可直接用new Uint8Array(event.data)处理 - 不写
[arrayBuffer]就等于没启用 transfer，仍走慢速克隆路径
大文件必须分片 + 带序号校验
即便用了 transfer，单次 send 仍受限于 iframe 生命周期和事件队列容量。100MB 文件不能一股脑塞进去，得切片 + 流控。
- 每片控制在 1–4MB，用
slice()提取子ArrayBuffer，再 transfer - 每片附带
{ id: number, total: number, data: ArrayBuffer }，避免乱序或丢片 - 接收方用
Uint8Array拼接，别用concat()（会拷贝）；推荐预分配new Uint8Array(totalSize)，按 offset 写入 - 发完一片后等对方回
ack再发下一片，防止 burst 导致消息积压丢失
中转层 contentWindow 失效导致 transfer 中断？
多级 iframe 场景下，transfer 对象无法跨层自动转发 —— postMessage 的 transfer 参数只对**直连目标窗口**生效。中间层若尝试中转，会报错或静默失败。
立即学习“前端免费学习笔记（深入）”；
- 孙级要收大文件，必须由父级直接发给孙级（通过
document.getElementById('grandchild').contentWindow），跳过中台层 - 若架构强制需经中台（如权限校验），中台层只能做「协议转换」：收到后解包、校验、重构成新
ArrayBuffer，再调用自己 target 的postMessage(..., [newBuffer]) - 每次重构都意味着一次内存分配和拷贝，性能损失显著 —— 所以设计时尽量扁平化层级
真正卡点不在 API 能力，而在你是否意识到 transfer 是一次性移交、不可复制、不可中转。漏掉 [buffer] 或试图跨 iframe 透传，就退回低效克隆模式。
