如何理解 JavaScript 原型链在跨标签页通讯如 postMessage 时的序列化损耗

在跨标签页通信中，postMessage 的性能瓶颈并非来自原型链，而是源于结构化克隆算法。理解这一点，有助于我们避开误区，聚焦真正的优化方向——数据形状与传输策略。

原型链本身并不参与跨标签页通信的序列化过程，因此不会带来任何额外损耗。事实上，postMessage 的序列化开销全部来自结构化克隆算法，而该算法在实现时完全忽略了原型链信息。

结构化克隆只保留“值”，不保留“原型”

当你调用 postMessage(obj, origin) 时，浏览器执行的是结构化克隆（Structured Clone），而非 JSON 序列化或基于原型链的深拷贝。请注意以下几个关键事实：

1. 克隆结果是一个全新对象，其 __proto__ 指向 Object.prototype（或对应内置构造器的原型，如 Date.prototype），与原对象的自定义原型链毫无关系。
2. 如果你传递的是 class Person { ... } 的实例，接收方收到的只是一个普通 plain object，既没有 Person.prototype 上的方法，也不满足 instanceof Person。
3. 函数、undefined、Symbol、constructor、getter/setter、循环引用等不可克隆项会被直接丢弃，原型链上的这些特性自然也随之消失。

真正影响性能的是数据“形状”，不是“原型”

序列化耗时取决于对象的结构特征，与其继承关系无关。具体来说：

1. 深层嵌套的对象或数组：克隆需递归遍历每一层，深度越大，栈开销和时间越长。
2. 大量小对象组成的集合（如 [{id:1},{id:2},...]）：比同等体积的扁平数组更慢，因为每个对象都要单独分配并检查可克隆性。
3. 含 ArrayBuffer 视图（Uint8Array）、Map、Set、Date 等类型：虽然支持克隆，但内部处理逻辑更重；若未使用 transfer，ArrayBuffer 还会触发完整内存拷贝。
4. 自定义原型上挂了方法或大字段？只要没有显式赋值到实例自身（即不在 obj.hasOwnProperty(key) 中），结构化克隆根本看不到它们。

误传“带原型的实例”反而埋下隐患

开发者有时会无意中把组件实例、状态管理器或调试对象传进 postMessage，以为只是“发个对象”。这类对象常常引发以下问题：

1. 闭包捕获了大量上下文变量（如组件实例持有 $data、$refs、$watchers），克隆时实际复制的是整个依赖图。
2. DOM 节点或 Event 对象不可克隆，postMessage 会静默失败或抛出 DataCloneError。
3. 即便成功克隆，接收方也无法调用原型方法——这不是损耗问题，而是功能断裂。

优化方向始终围绕“数据精简”和“传输方式”

与其纠结原型链是否被序列化，不如聚焦于你实际传输了什么、怎么传输。以下为具体优化建议：

1. 发送前做数据净化：使用解构、Object.assign({}, pick(obj, ['id', 'name'])) 只留必要字段。
2. 大数据量（如图片像素、日志块）改走 Blob URL 或 IndexedDB，postMessage 只传路径或 key。
3. 高频消息（如拖拽坐标）加节流，合并为单次 payload，避免每帧都触发克隆。
4. 需要零拷贝传递二进制数据时，明确使用 transfer 参数移交 ArrayBuffer，此时连克隆都跳过。

总而言之，提升 postMessage 传输效率的核心在于精简数据体积、优化传输路径，而非担忧原型链造成的损耗，后者实际上从未成为性能瓶颈。