ES6的extends本身不自动解耦，需通过职责分离、合理调用super、封装字段、配置化易变逻辑、避免构造器中调用可重写方法、优先组合而非继承、多态替代类型判断等设计实践实现真正解耦。
ES6 的 extends 本身不自动解耦，解耦靠设计意识和使用方式。关键不是“用了 extends 就解耦了”，而是通过明确职责边界、合理调用 super、避免强依赖，让父类逻辑可独立演进，子类只扩展不破坏。
父类只暴露稳定契约，不暴露实现细节
父类方法应聚焦“做什么”，而非“怎么做”。比如定义 save()，但内部不硬编码数据库连接或日志格式；子类重写时只需关注自己的存储方式，不用改父类代码。
- 把易变逻辑（如 API 地址、校验规则、缓存策略）抽成可配置参数或 protected 方法，供子类覆盖
- 避免在父类构造器里调用子类可能重写的方法（会触发未初始化的 this）
- 用 getter/setter 封装字段访问，而不是直接暴露
this.data—— 子类可通过重写 getter 控制读取逻辑
子类重写时用 super 调用，而非复制粘贴
当子类需要增强父类行为（比如加权限检查、埋点、兜底处理），应在自己方法中调用 super.methodName()，而不是把父类整段逻辑抄过来再改。
- 这样父类逻辑升级后，子类自动受益，无需同步修改
- 若父类
fetch()增加了自动重试机制，所有调用super.fetch()的子类立刻获得该能力 - 禁止在子类里写和父类一模一样的方法体——那是重复，不是复用
区分“继承”和“组合”，该用组合时不硬套 extends
不是所有共性都适合用继承。当两个类只是“用到了相同工具”，而不是“是一种”，就该用组合。
- 比如多个类都要发请求，与其让它们都
extends ApiClient，不如各自持有一个apiClient实例 - 父类不应塞进大量仅被部分子类使用的功能（如
exportToExcel()只有报表类需要） - 接口（
implements）+ 默认方法 或 mixin 函数，比深继承链更利于解耦
用 instanceof 和类型守卫控制依赖流向
父类代码里尽量不出现对具体子类的判断或调用。如果必须差异化处理，用多态代替条件分支。
- 错：父类里写
if (this instanceof PaymentCard) { ... } - 对：定义抽象方法
getFeeRate()，由各子类实现，父类统一调用 - 运行时验证用
instanceof是为了安全转型，不是为了写 if-else 分支逻辑
