继承滥用会导致子类脆弱、封装失效和LSP违规；应优先用组合+接口，仅在满足is-a清晰、契约稳定、不覆盖核心流程、模板方法收口四条件时才使用继承。
继承会让父类一改，子类全崩
这是最常踩的坑：你只是给 OrderService 的 validate() 方法加了个日志，结果 PromotionOrderService、RefundOrderService 等 17 个子类全报 NullPointerException 或逻辑错乱。因为它们都依赖父类中某个被悄悄修改的 protected 字段或方法执行顺序。
- 子类无法控制父类构造逻辑，一旦父类构造器里做了高风险操作（比如初始化第三方 SDK），子类实例化就可能直接失败
- 父类新增一个
protected void onInit()，而某个子类恰好已有同签名方法但语义不同，运行时行为就不可预测 - 多层继承（
A → B → C → D）下，调试时得顺着调用链翻四层源码，还分不清哪一层改了哪一行
Java单继承 + protected暴露 = 封装形同虚设
写个 BaseCache 类，把 cacheMap 设为 protected 方便子类直接读写——结果所有子类都开始绕过 put() 和 evict() 方法，直接操作 cacheMap，导致缓存一致性彻底失控。
-
protected不是“受保护”，而是“半公开”：它把实现细节暴露给所有子类，等于把封装锁换成了弹簧门 - 接口（
implements）只承诺行为，不暴露状态；而extends把字段、初始化顺序、方法调用链全打包塞给子类 - 想复用逻辑？用组合 + 接口回调更安全：
private final CacheEngine engine = new CaffeineCacheEngine();，替换引擎只需改一行
里氏替换原则不是理论，是线上事故预警灯
有个 ImmutableListWrapper 继承 ArrayList，重写了 add() 抛异常。结果某处代码写着 if (list instanceof ArrayList) { list.add(item); }，一跑就崩——这违反了 LSP：子类不能让父类使用者的逻辑失效。
- 子类覆盖方法时，不能缩小访问权限（如
public → protected）、不能抛出父类没声明的受检异常、不能改变返回值的可变性语义 - 如果发现子类总在重写父类方法来“禁用”功能，说明继承关系错了，应该用组合 + 显式能力声明（比如
ReadonlyList实现ReadOnlyCollection接口） - 单元测试里加一条断言：
assertThat(subInstance, is(instanceOf(Parent.class)));不够，还得验证行为等价性
替代方案不是“不用继承”，而是“用对地方”
真要继承？只在满足这四个条件时才考虑：is-a 关系绝对清晰、父类契约稳定不变、子类不覆盖核心流程、扩展点通过模板方法严格收口（比如 abstract void doProcess()）。
立即学习“Java免费学习笔记（深入）”；
- 日常业务对象（
User、Order、Product）之间几乎不存在严格的is-a，别硬套BaseEntity继承链 -
工具类、配置类、DTO 更不该被继承——用
@Builder、Record、interface default method替代 - 框架集成（如 Spring 的
ApplicationRunner、MyBatis 的BaseMapper）是少数合理继承场景，但注意它们本身已用模板方法封死了扩展边界
真正难的不是写 extends，是判断那个 new 出来的对象，到底该持有另一个对象，还是假装自己是它。
