彻底搞懂JavaScript原型链的工作机制与常见误区

「又踩坑了，instanceof 失效，对象明明是 new 出来的却判 false」

今天上线前测一个表单组件，发现校验逻辑里一句 if (value instanceof MyValidator) 死活进不去——可我明明是 new MyValidator() 出来的啊！控制台打印 value.constructor 确实是 MyValidator，但 instanceof 就是返回 false。折腾了快一小时，最后发现是原型链被悄悄改过……

先说结论：问题出在我们用了 Webpack 的 externals 配置把 lodash 提出来，然后又在另一个包里单独 import { cloneDeep } from 'lodash'，结果导致两个模块里各自加载了一份 lodash，而我们的校验类内部用到了 cloneDeep 做深拷贝，拷出来的对象的原型链里，constructor 指向的是「另一个 lodash 实例里的构造器」——不是当前模块作用域下的那个。

这里我踩了个坑：一直以为 instanceof 只看构造函数名，其实它比对的是「右边构造函数的 prototype 是否在左边对象的原型链上」。只要原型链断了，哪怕函数名一模一样，也白搭。

后来试了下发现更诡异的点：在本地开发（Webpack dev server）里一切正常，但 build 后的生产包就挂了。一开始我还怀疑是 Tree-shaking 把啥干掉了，甚至去翻了 Webpack 的 module.rules 有没有误配 babel-loader，结果全都是虚惊一场。

真正定位到问题，靠的是这行调试代码：

console.log(value.__proto__ === MyValidator.prototype); // false
console.log(value.constructor === MyValidator); // true（表面看没问题）
console.log(Object.getPrototypeOf(value) === MyValidator.prototype); // false
console.log(Object.getPrototypeOf(value)); // 输出一个看起来像 MyValidator.prototype 的对象，但 !==

再往上查一层：Object.getPrototypeOf(Object.getPrototypeOf(value))，发现它指向了一个陌生的 Object，而不是 MyValidator.prototype。这时候我才意识到：这个 value 是被某个跨模块的深拷贝函数处理过的，它的 __proto__ 被重写了，而且写的是「另一份 lodash 的私有原型副本」。

为啥会这样？因为 lodash.cloneDeep 在克隆时，如果目标对象有自定义 constructor，它会尝试用该 constructor 新建实例并赋值属性，但它新建的时候，用的是它自己模块作用域里的 MyValidator —— 而不是你当前模块 import 进来的那个。尤其当 MyValidator 是一个非全局、非 esm 共享导出的类（比如它藏在某个 utils 包里，且没做 proper export），那 webpack 打包后很可能生成两份独立的类定义。

解决方案其实不复杂：要么别用深拷贝来“伪造”实例，要么统一构造逻辑。我选了后者——改用 Object.assign(new MyValidator(), source) 替代 cloneDeep，只浅拷贝一层关键字段，跳过方法和原型继承部分。毕竟这个校验器本身也不需要完整复制所有闭包状态，只需要配置参数一致就行。

但如果你真得深拷贝整个实例（比如要做回滚、快照），那得绕开 cloneDeep 的 constructor 自动调用机制。最终我补了这么一段封装：

function safeCloneInstance(instance) {
  const ctor = instance.constructor;
  const plainObj = JSON.parse(JSON.stringify(instance));
  // 注意：这里只处理可序列化字段，忽略函数、Symbol、undefined 等
  const cloned = Object.assign(new ctor(), plainObj);
  // 如果有不可序列化的字段（比如缓存 map），手动补
  if (instance._cache && typeof instance._cache === 'object') {
    cloned._cache = new Map(instance._cache);
  }
  return cloned;
}

这段代码不依赖任何三方库，只用原生 API，保证构造函数永远是你当前模块 scope 下的那个。虽然丢了 Symbol 和函数，但对我们场景够用了。上线后 instanceof 终于稳了。

顺带一提，我也试过强行修复原型链：value.__proto__ = MyValidator.prototype，但立刻被 Vue 的响应式系统报错（Cannot assign to read only property '__proto__'）。后来发现 Vue 3 默认用 Proxy，但某些旧插件或 defineProperty 拦截的场景下，__proto__ 是只读的，改不了。所以这条路直接 pass。

还有个备选方案是用 Reflect.construct，但兼容性要查一下（IE 不行，不过我们项目已放弃 IE）。试了下：

const cloned = Reflect.construct(
  MyValidator,
  [],
  MyValidator
);
Object.assign(cloned, instance); // 再手动赋值

效果类似，但多了个构造调用开销，而且如果 MyValidator 构造函数里有副作用（比如发请求、绑定事件），就得小心了。我们没选这个，太重。

踩坑提醒：这三点一定注意：

• 不要迷信 constructor === XXX 就等于 instanceof XXX，它们判断逻辑完全不同；
• 跨模块共享类时，确保它走的是同一份 ESM 导出（比如从一个入口 index.js 统一 re-export），避免多个包各自 import 同名类却拿到不同引用；
• lodash.cloneDeep 对自定义类的行为是「尽量还原结构」，不是「严格保持 instanceof 关系」，这点文档里其实写了，但我当时没细看……

另外补充个细节：我们项目里还用了 micro-frontend 架构，主应用和子应用各自打包，子应用里也定义了 MyValidator。结果某次联调发现，主应用传给子应用的对象，在子应用里 instanceof 判 false，原因一样——两边的 MyValidator 是两个内存地址。后来我们改成只传 plain object，子应用自己 new，彻底规避。

最后说下现状：改完之后，95% 的 case 都稳了。还有 2% 的边缘 case 是某些老数据里嵌套了 Date 或 RegExp，JSON 序列化后类型丢失，导致校验失败。不过那是业务数据清洗的问题，跟原型链无关了，加个 warn 日志提示下前端补格式就行，不影响主流程。

以上是我踩坑后的总结，希望对你有帮助。如果你有更好的方案（比如用 structuredClone + 自定义 hook，或者用 class-transformer 那套映射机制），欢迎评论区交流。