组合优于继承是真实项目踩坑后形成的务实选择，用于解决类爆炸和变量耦合问题，核心是用“有一个”替代“是一个”，通过接口抽象与运行时注入实现松耦合。
组合优于继承不是一句口号，而是在真实项目里反复踩坑后沉淀下来的务实选择。它直接应对两个高频痛点：类爆炸（比如为每种支付方式、每种通知渠道都建一个子类）和变量耦合（子类意外依赖父类的 protected 字段或未初始化状态）。核心思路很朴素——用“有一个”代替“是一个”，把可变部分抽成接口，运行时注入，而不是编译期绑定。
什么时候继承真该被拦下来？
看到以下信号，就该暂停继承设计，转而考虑组合：
- 父类没声明为 abstract，也没文档说明“专为继承设计”，只是普通类——它本意可能只是被用，不是被扩
- 子类重写方法时频繁调用 super.xxx()，或者必须记住“不调 super 就丢日志/权限校验”——这暴露了父类实现细节，已属脆弱耦合
- 想加一个新行为（比如“支持离线缓存”），却发现要横跨三四个继承层级去改，或者得新增一个中间抽象类——结构已僵化
- 遇到 Cannot inherit from final 'xxx' 编译错误，第一反应不是找字节码工具绕过，而是定义包装类持有该实例
组合不是简单套个字段，关键在接口粒度
组合失效往往不是因为原则错了，而是接口设计太宽或太窄：
- 别让组合类暴露所有 delegate 方法，比如 PaymentProcessor 包含 Strategy，就只暴露 process() 和 refund()，不暴露 Strategy 内部的 validate() 或 format() ——避免变成“胖包装器”
- 接口命名要反映业务意图，而不是技术动作。用 PaymentStrategy 比用 IPaymentHandler 更易理解；用 NotificationChannel 比用 INotifier 更聚焦职责
- 构造时注入优于 setter 注入，能保证对象一创建就处于可用状态，避免空指针或半初始化风险
继承没被淘汰，但它有明确的适用边界
框架集成和语义清晰的 is-a 场景，继承仍是合理甚至必需的选择：
- Spring MVC 中统一继承 BaseController 做权限拦截和日志模板，这是框架契约，硬套组合反而增加适配成本
- 领域模型中 Ostrich extends Bird 不成立，但 AdminUser extends User 成立——前者行为冲突（飞/不飞），后者是纯粹的权限扩展，无逻辑覆盖
- 模板方法模式（如 AbstractService.execute() 调用 doExecute()）是继承的典型正向用例，父类控制流程骨架，子类填充差异点
组合带来的隐性收益：升级更稳、测试更轻
这些好处常被忽略，却直接影响交付节奏：
- JDK 升级时，java.util.AbstractList 内部实现调整曾导致大量自定义 List 子类 add() 行为异常；组合对象因只依赖 public 接口，完全不受影响
- 单元测试时，组合类可直接 mock 掉 Strategy 或 Channel 实例，无需启动 Spring 上下文或构造复杂继承链
- 灰度发布新策略时，只需替换 Spring Bean，不用发新子类 jar 包，发布粒度从“类”降到“实现”
