在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 中的对象生命周期与主线程是隔离的，原型链仅仅是本地上下文中的概念。验证数据合规性的核心，不是看它看起来像不像某个类，而是检查它是否具备应有的字段和约束。