ES5中仅依赖[[Prototype]]检查时，省略constructor修复有何风险？

在ES5中实现寄生组合继承模式时，绝大多数资料（包括Nicholas Zakas的著作）都要求按如下方式修复constructor属性：

function inheritPrototype(childSide, parentSide) {
  childSide.prototype = Object.create(parentSide.prototype);
  // Is this line below actually necessary in ES5?
  childSide.prototype.constructor = childSide; 
}

但从OLOO（对象链接到其他对象）的视角来看，.constructor属性是为让JavaScript模仿类式语言而遗留的脆弱、易产生误导的特性。若架构明确禁止使用instance.constructor进行类型检查，且严格采用Object.getPrototypeOf(instance)、Parent.prototype.isPrototypeOf(instance)等ES5/ES6现代诊断工具，完全省略constructor修正语句会存在哪些实际技术风险？JavaScript运行时或标准内置方法中是否存在因.constructor缺失或“损坏”而导致原生错误的隐藏场景，还是说这仅仅是第三方库的约定？

回答 #

• 原生运行时无核心风险：ES5及后续版本的标准内置方法，不会依赖constructor属性执行核心逻辑。比如数组的map、filter，或是Object系列原生方法，都不会因为实例的constructor指向父类而抛出错误。JavaScript引擎的类型判断依赖的是内部的[[Prototype]]链，而非这个暴露在外的constructor属性。
• 风险仅来自第三方代码或旧约定：
  • 部分第三方库（尤其是类库、框架）可能会在内部用instance.constructor做类型判断、实例创建（比如调用new instance.constructor()生成同类型实例），如果省略constructor修正，这类库可能出现不符合预期的行为。
  • 团队内部若有旧代码习惯或文档约定了constructor的使用，即便架构明确禁止，也可能有人误用，引发逻辑bug。
• OLOO模式下可安全省略：既然你的架构已经明确用Object.getPrototypeOf、isPrototypeOf这些现代工具做类型检查，那constructor修正确实是多余的。OLOO本身基于原型链直接链接，不需要维护这个模仿类的constructor属性，完全可以放心省略。

内容的提问来源于stack exchange，提问作者krabat1