constructor仅适用于开发调试等非关键场景，如控制台验证、类内轻量推导或受控工厂方法；其三大陷阱是原型替换丢失、继承未修复和显式篡改；应优先用instanceof、Object.prototype.toString.call()等更可靠方案。
用 constructor 判断类型，看似直观，实则暗藏风险。它适合快速调试或非关键路径的类型提示，但绝不能用于安全校验、序列化还原或核心逻辑分支。
哪些场景下可以用 constructor？
它在开发阶段辅助识别对象来源较方便，前提是环境可控、原型未被污染：
- 控制台临时验证：比如
arr.constructor === Array快速确认数组是否“干净” - 工厂方法中创建同类型新实例（需配合防护）：如
clone() { return new this.constructor(...args); }，但必须确保this.constructor未被覆盖 - 类内部方法中做轻量级类型推导：例如子类重写方法后想返回自身类型实例，可写
return new this.constructor()，前提是使用class语法（其prototype.constructor默认不可配置）
constructor 最常见的三个陷阱
它的不可靠性主要来自可写性与原型操作的副作用：
-
原型被整体替换时丢失：比如
MyClass.prototype = { method() {} };后，instance.constructor指向Object，而非MyClass -
第三方库或继承代码未修复：旧式继承（如寄生组合式）常漏写
SubType.prototype.constructor = SubType，导致子类实例的constructor仍指向父类 -
被显式篡改却无感知：任何代码都可执行
obj.constructor = String或Array.prototype.constructor = Object，后续所有基于该属性的判断都会失效
比 constructor 更稳妥的替代方案
多数情况下，应优先选用语义更明确、机制更底层的方式：
- 判断是否为某类实例 → 用
obj instanceof MyClass（注意跨 iframe 失效，此时可用toString补充） - 精确识别内置对象类型（如
Array、Date、Map）→ 用Object.prototype.toString.call(obj)，返回[object Array]等标准字符串 - 需要获取原型本身 → 用
Object.getPrototypeOf(obj) === MyClass.prototype，绕过constructor这一中间引用 - 基本类型检测（
null、undefined、symbol等）→typeof仍是首选，但记得单独处理null（typeof null === 'object'）
如果非要依赖 constructor，至少做两件事
降低出错概率，不是消除风险：
- 在重写原型后立即手动恢复：
MyClass.prototype.constructor = MyClass - 关键逻辑中加兜底校验：比如
if (obj.constructor === MyClass && obj instanceof MyClass)，双保险
