重写子类prototype后constructor指向错误的根本原因是新原型对象没有自有constructor属性，需沿原型链查找。修复方式有三种：直接赋值、字面量内联声明、defineproperty定义；修复后仍应使用instanceof而非constructor判断类型。
重写子类 prototype 后，constructor 指向出错是原型继承中非常典型的陷阱。根本原因不是“指向被改了”，而是新赋值的原型对象压根没有自己的 constructor 属性，导致访问时沿原型链向上查到父类或 Object 的构造函数。
为什么重写 prototype 后 constructor 会丢失
每个函数的 prototype 默认自带 constructor 属性，指向自身。但一旦你执行类似 Child.prototype = Object.create(Parent.prototype) 或 Child.prototype = { say() {} } 这样的操作，就相当于用一个全新对象替换了原来的 prototype。这个新对象：
- 如果是
Object.create创建的，它没有自有constructor，会继承自Parent.prototype.constructor - 如果是字面量
{}，它也没有constructor，最终查到Object.prototype.constructor - 实例本身不存
constructor，全靠原型链提供 —— 所以源头错了，所有实例都会错
三种安全修复方式
目标是让 Child.prototype 自身拥有正确、稳定、不易被干扰的 constructor 属性：
-
直接赋值（适合快速验证）：
Child.prototype.constructor = Child;简单有效，但该属性可枚举、可写，后续for...in或Object.assign可能覆盖它 -
字面量内联声明（语义清晰）：
Child.prototype = { constructor: Child, say() {} };注意必须一次性赋值，不能先赋空对象再补constructor，否则无效 -
defineProperty 定义（推荐生产环境）：
Object.defineProperty(Child.prototype, "constructor", { value: Child, writable: true, enumerable: false, configurable: true });不可枚举，避开JSON.stringify和遍历干扰；writable允许必要时修正；configurable支持后续调整
修复后仍要注意的关键点
即使 constructor 指向已修正，也不能把它当作类型判断的可靠依据：
-
obj.constructor === Child不安全 —— 该属性可被任意代码修改 - 应优先使用
obj instanceof Child或Child.prototype.isPrototypeOf(obj)，它们基于真实的原型链，无法伪造 - ES6
class虽自动维护constructor，但若运行时手动混入方法（如Object.assign(Child.prototype, mixin)），仍可能覆盖它，需额外检查
不复杂但容易忽略：每次重写 prototype，都要同步处理 constructor。这不是补救，而是继承逻辑完整性的基本要求。
