JavaScript原型链在跨页通讯中的序列化损耗解析

在跨标签页通信场景中，许多人会顾虑对象的原型链是否会被序列化，并因此产生额外的性能开销。实际上，这是一个普遍的误解。原型链本身并不参与序列化过程，性能的关键在于你所传递的数据“形状”。

结构化克隆仅处理数据值，不保留原型信息

当你调用 postMessage(obj, origin) 时，浏览器执行的是结构化克隆算法，而非基于原型链的深拷贝。该算法的核心原则是：只克隆数据本身，忽略所有与继承相关的信息。

• 克隆结果是一个全新的对象，其 __proto__ 会指向 Object.prototype（或对应内置构造函数的原型，如 Date.prototype），与原对象的自定义原型链无关。
• 如果你传递的是一个 class Person { ... } 的实例，接收方收到的将只是一个普通对象。它不具备 Person.prototype 上的方法，也无法通过 instanceof Person 的检查。
• 对于函数、undefined、Symbol、构造函数、getter/setter 以及循环引用等不可克隆项，算法会直接丢弃。原型链上的这些特性也随之消失。

影响性能的关键是数据形状，而非原型链

序列化的耗时完全取决于对象的结构特征，而不是它的继承关系。以下几个因素才是关键：

• 深层嵌套的对象或数组：克隆过程需要递归遍历每一层，深度越大，栈开销和时间成本越高。
• 由大量小对象组成的集合（例如 [{id:1},{id:2},...]）：这比同等体积的扁平数组更慢，因为每个对象都需要单独分配内存并检查其可克隆性。
• 包含复杂类型的数据：如 ArrayBuffer 视图（Uint8Array）、Map、Set、Date 等。虽然它们支持克隆，但内部处理逻辑更复杂。如果未使用 transfer 参数，ArrayBuffer 还会触发完整的内存拷贝。
• 至于自定义原型上挂载的方法或大字段？只要它们没有被显式赋值到实例自身（即不在 obj.hasOwnProperty(key) 的范围内），结构化克隆算法就“看”不到它们，自然也谈不上性能损耗。

误传带原型的实例可能带来隐患

开发者有时会无意中将组件实例、状态管理器或调试对象传入 postMessage，认为只是传递一个普通对象。这类对象往往隐藏着风险：

• 闭包捕获了大量上下文变量：例如 Vue 组件实例持有 $data、$refs、$watchers 等。克隆时实际复制的是整个依赖图，数据量远超预期。
• 包含不可克隆的宿主对象：如 DOM 节点或 Event 对象。postMessage 会静默失败或直接抛出 DataCloneError。
• 即便成功克隆，接收方也无法调用原型上的方法——这已不仅是性能问题，更是功能上的断裂。

优化应聚焦于数据精简与传输方式

因此，无需纠结原型链是否被序列化。真正的优化应聚焦于实际传递的内容以及传递方式。

• 发送前进行数据净化：使用解构或 Object.assign({}, pick(obj, ['id', 'name'])) 等方式，只提取必要的字段。
• 大数据量改用专用通道：对于图片像素、日志块等大数据，可考虑使用 Blob URL 或 IndexedDB 存储，postMessage 只传递路径或 key。
• 高频消息进行合并与节流：例如拖拽坐标更新，可以合并为单次 payload 发送，避免每帧都触发克隆。
• 善用 transfer 实现零拷贝：当需要传递二进制数据时，明确使用 transfer 参数移交 ArrayBuffer 的所有权，此时连克隆步骤都可以跳过。