跨线程场景下，使用 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.prototypeclass Task {}; const t = new Task();→Object.getPrototypeOf(t) === Task.prototype
不过有一点需要注意：这些对象不能直接传回主线程，因为传回去还要经历一次克隆，原型同样会丢失。如果确实需要返回数据，仍然必须转为纯数据结构。
归根结底，这并不复杂，但确实容易忽视：Worker 中的对象生命周期与主线程是隔离的，原型链仅仅是本地上下文中的概念。验证数据合规性的核心，不是看它看起来像不像某个类，而是检查它是否具备应有的字段和约束。
