Worker线程间 如何使用 getPrototypeOf 深度验证 对象合规性

在跨线程场景中，使用 Object.getPrototypeOf 判断对象类型，这一思路本身是合理的。但问题在于，一旦进入 Worker 线程，该方法便会失效。

这源于结构化克隆的底层限制：主线程与 Worker 之间传递的数据会经历序列化与反序列化过程，原型链在此过程中彻底断裂。最终得到的数据实际上是一个普通的 plain object，既没有 constructor，也没有原型方法，更不保留任何继承关系。

为什么 getPrototypeOf 在 Worker 中对传入对象失效

原因非常直接：Worker 接收的数据必须能够被结构化克隆。简单来说，JSON 能够表示的那些类型可以正常传递；但函数、class 实例、Date、Map、Set、Promise 以及任何带有原型链的方法对象，都会被“降级”为普通对象。

• new Date() 会变为普通 object，Date.prototype 不复存在。
• class User {} 的实例会被扁平化为 {}，此时 Object.getPrototypeOf(obj) 只能返回 Object.prototype。
• 即便手动在 postMessage 中添加 __type: 'User' 标记，原型也无法恢复。结构化克隆并不会理会这类自定义标记。

替代方案：基于 schema 的运行时校验

原型既然不可靠，就不要依赖它。更好的做法是采用明确的类型标识加上数据结构校验。

• 主线程发送数据前，先附加一层元信息：postMessage({ type: 'UserProfile', data: { name: 'Alice', id: 123 } })。
• Worker 内部定义校验规则，可以使用轻量库（比如 AJV），也可以手动编写逻辑。
• 检查 msg.type 是否在白名单内，再对 msg.data 进行字段类型、必填项、格式（如 email、url）校验。
• 校验失败时直接抛出错误：new Error(`Invalid ${msg.type}`)，主线程捕获时逻辑清晰。

这种方式绕开了原型链的限制，保证了数据合规性，同时也便于调试。

若需保留行为，改用 Transferable + 自定义序列化

如果场景特殊，确实需要保留对象的某些“形态”，也不是无计可施。例如在频繁的数值计算场景中，可以考虑如下做法：

• 只传输 ArrayBuffer 或 TypedArray，Worker 用相同的构造函数重建视图，比如 new Float32Array(buffer)。
• 对于复杂对象，提前序列化为兼容 JSON Schema 的结构，并附带一个 $schema 字段，Worker 内部加载对应的校验器。
• 不要试图恢复原型——既不可靠，也存在安全隐患。行为逻辑应当封装在 Worker 内部的函数里，而非依赖传入对象的方法。

Worker 内部对象的原型验证仍有效

反过来看，在 Worker 内部自己创建的对象，原型验证是完全可用的。

• const arr = []; → Object.getPrototypeOf(arr) === Array.prototype。
• class Task {}; const t = new Task(); → Object.getPrototypeOf(t) === Task.prototype。

不过有一点需要注意：这些对象不能直接传回主线程，因为传回去又要经过一次克隆，原型依然会丢失。如果需要返回数据，仍然必须转为纯数据结构。

归根结底，这个问题并不复杂，但确实容易被忽视：Worker 的对象生命周期与主线程是隔离的，原型链只是本地上下文中的概念。验证合规性，核心不在于对象看起来像不像某个类，而在于它是否包含应有的字段和约束。