原型继承中子类重写父类方法本身不是错误，而是设计意图的体现；关键在于明确重写目的是增强、替换还是组合，并通过super调用、显式声明、注释说明及合理钩子设计来避免逻辑混乱与语义不清。
原型继承中子类重写父类方法本身不是错误，而是设计意图的体现；所谓“冲突”通常指调用逻辑混乱、父类行为被意外丢失，或同名方法导致语义不清。关键在于明确重写的目的是增强、替换还是组合，再选择对应处理方式。
明确重写意图，决定是否覆盖
如果子类方法只是对父类逻辑做补充（比如新增日志、校验），不应完全覆盖，而应保留父类执行路径：
- 在子类方法中主动调用 super.方法名()（ES6 class 语法）或 Parent.prototype.方法名.call(this)（原型链手动调用）
- 避免直接赋值覆盖原型方法，例如不要写
Child.prototype.init = function() { ... }而不调用父类 init - 若确实需彻底替换（如不同算法实现），则重写合理，无需回避 —— 冲突感往往来自未同步文档或调用方预期错位
避免隐式覆盖，用显式声明替代静默替换
JavaScript 原型链上方法查找是动态的，子类同名方法会自然屏蔽父类方法。为减少歧义：
- 重写时加注释说明与父类方法的关系，例如 “扩展父类 validate，增加格式检查”
- 对非必须重写的方法，优先通过参数或配置定制行为，而非重定义方法体
- 若多个子类都重写同一父类方法，考虑将共性提取为父类可配置钩子（hook），例如
this.beforeSave()留空供子类实现
访问被遮蔽的父类方法要可靠
一旦子类定义了同名方法，实例调用默认执行子类版本。需要父类原始逻辑时，不能依赖 this.method()，而必须显式定位：
- 使用 super.method()（仅限 class 语法且在子类方法内部）
- 使用 Parent.prototype.method.call(this)（适用于任意原型链场景，更底层也更可控）
- 避免依赖
this.__proto__.__proto__.method()这类脆弱写法，MRO 不稳定且不可读
静态方法和构造器也要统一管理
构造函数或静态方法不会自动继承，常被忽略导致“方法丢失”假象：
- 子类构造器中必须显式调用 super(...)，否则 new 子类实例可能缺少父类初始化逻辑
- 静态方法不会沿原型链查找，子类需自行定义或转发，例如
static create() { return new this(); } - 若父类有静态工具方法（如
Parent.fromJSON()），子类应覆写并调用父类实现，再叠加自身逻辑
