Java继承是一把双刃剑：它提升复用与结构清晰，但易引发紧耦合、脆弱基类、语义失真和测试爆炸等问题；推荐优先使用组合+接口、策略模式等更可控的替代方案。
Java继承在带来代码复用和结构清晰的同时，也引入了一些实际开发中容易被忽视的设计隐患。它不是“用不用”的问题，而是“怎么用才安全、可维护”的问题。
紧耦合：父类一动，子类跟着抖
子类直接依赖父类的实现细节，一旦父类修改字段、方法签名或逻辑（比如重构protected方法），所有子类都可能意外失效。这种依赖是隐式的、跨文件的，编译器难检查，运行时才暴露。
- 父类加了一个非空校验，子类重写的同名方法没同步处理，就可能抛NPE
- 父类把某个public方法改为final，原本想覆盖它的子类立刻编译失败
- IDE重构父类方法名时，默认不自动更新子类中的super调用，靠人工容易漏
脆弱的基类问题（Fragile Base Class Problem）
父类看似稳定，但内部调用顺序、钩子方法（如模板方法里的hook）一旦调整，子类行为就可能错乱——尤其当子类通过重写影响了父类控制流。
- 父类构造器里调用了可被重写的方法，子类该方法访问了还没初始化的字段，直接NPE
- 父类用“先set再init”模式，子类重写了set却没意识到init会依赖其结果
- 日志、事务、权限等横切逻辑若放在父类方法中，子类覆盖后容易绕过关键检查
继承层级过深，语义逐渐失真
超过3层的继承链（比如Animal → Mammal → Carnivore → Dog → GuardDog）会让代码越来越难理解：“GuardDog到底继承了哪些行为？哪些被覆盖了？哪些只是名义上存在？”
立即学习“Java免费学习笔记（深入）”；
- 子类可能只用到父类10%的功能，却被迫继承全部字段和方法（包括private不可见但占用内存的）
- is-a关系开始模糊：一个“BillingProcessor”继承“ReportGenerator”，仅仅因为都要写文件？这不是类型关系，是功能拼凑
- 单元测试爆炸：每层都要测，还要测组合场景，mock难度指数上升
替代方案更轻量、更可控
多数场景下，组合+接口比继承更稳妥。Java 8+默认方法、Records、sealed class也在弱化对深度继承的依赖。
- 用接口定义能力（Runnable、Comparable），用组合注入具体行为（比如PaymentStrategy）
- 把共通逻辑抽成工具类或静态方法，避免强制建父子关系
- 需要“扩展点”时，优先考虑回调、函数式参数（Consumer
）、策略模式，而不是留abstract方法等子类填
基本上就这些。继承不是坏东西，但它是把双刃剑——用在明确的、稳定的、真正符合is-a的场景（比如JDK里的InputStream体系）很优雅；用在业务模型快速演进、职责边界模糊的地方，就容易变成技术债加速器。
