组合是生命周期强绑定的“我创建你，你活在我里面”，如Car含private final Engine；聚合是“我用你但你不归我管”，如Department持Employee引用；关键看部分离开整体能否独立存在。
组合就是“我创建你，你活在我里面”
组合关系的本质是生命周期强绑定：整体类在构造时 new 出部分对象，且该部分对象不对外暴露、不可替换、不能脱离整体独立使用。一旦整体对象被 GC 回收，部分对象若无其他引用，也会随之不可达——这不是靠手动清理，而是语义上它本就不该存在。
- 典型场景：一个
Car必须自带Engine才算完整；卸下来的引擎在业务上已不是“汽车引擎”，而是废件 - 代码标志：构造函数里直接
new Engine()，字段用private final Engine engine声明 - 常见误用：把
PaymentStrategy通过new CreditCardStrategy()硬编码进OrderProcessor——这破坏了策略的可替换性，实际应是聚合
聚合就是“我用你，但你不归我管”
聚合的关键在于“借用”而非“占有”：整体类只持有一个外部创建的对象引用，不参与其生命周期管理，也不限制它被其他对象复用。哪怕整体销毁，部分对象仍可继续工作。
- 典型场景：一个
Department持有多个Employee引用；员工离职后依然存在，甚至能加入另一个部门 - 代码标志：构造参数或 setter 接收已有实例，如
public Department(List，内部绝不用members) new Employee() - 容易踩坑：误将数据库连接池中的
Connection对象在服务类里new出来——Connection 应由 DataSource 提供，属于典型的聚合关系
怎么一眼分辨组合还是聚合？看这句话能不能成立
面对两个类，问自己一句：“这个部分，离开整体还能活吗？”
- 能活 → 聚合（如轮胎、员工、缓存客户端
RedisTemplate） - 不能活 → 组合（如汽车的引擎、订单的唯一编号生成器
OrderIdGenerator、GUI 窗体里的JPanel） - 模棱两可 → 很可能建模错了，得回业务现场确认：那个“部分”在真实系统中是否真的会被复用、共享、或单独测试？
别用继承代替组合，也别用组合假装聚合
组合和聚合都是 has-a，但它们和 is-a（继承）完全不在一个维度。用错关系会导致重构成本飙升。
立即学习“Java免费学习笔记（深入）”；
- 用继承模拟“汽车有引擎”？
class Car extends Engine——语义错误，且违反单一职责 - 用组合硬塞外部对象？
this.engine = engineFromOutside;却声明为final+ 不提供替换入口 ——表面是组合，实则是泄漏的聚合，后期无法 mock 测试 - 真正灵活的设计：组合用于不可拆解的核心部件（如加密密钥管理器），聚合用于可插拔协作组件（如日志上报服务
LogReporter）
最常被忽略的一点：UML 图里实心菱形（组合）和空心菱形（聚合）不是画着好看的——它直接对应你在构造函数里写不写 new，以及单元测试时要不要为那个“部分”准备 mock 实例。
