java中区分关联、聚合、组合关键看生命周期绑定：关联最松（对象独立销毁），聚合可分离（部分可属多个整体），组合最紧（部分随整体销毁，内部构造且无外部引用）。
Java里怎么区分关联、聚合和组合？关键看生命周期是否绑定
三者本质都是“has-a”关系，区别只在对象销毁时的依赖强度：关联最松，组合最紧。别被UML图迷惑——代码里没关键字，全靠构造逻辑和引用管理体现。
- 关联：两个对象各自独立创建，
user持有address引用，但删掉user不影响address存活 - 聚合：整体和部分可分离，
department包含employee列表，但employee可以属于多个部门，也能单独存在 - 组合：部分完全隶属于整体，
car创建时 new 出engine，car销毁时engine必须一起销毁（通常不暴露engine的 setter 或外部构造）
写代码时怎么避免把组合写成聚合？重点看构造和赋值方式
组合不是靠注释或命名约定，而是由实例化时机和所有权决定。常见错误是把本该内部构造的对象，改成从外部传入。
- 组合正确写法：
Car构造器里直接new Engine()，不提供setEngine(Engine)方法 - 聚合常见误写：
Car接收外部传入的engine，且该engine可能还在其他地方被引用（比如被Truck也持有） - 关联典型场景：
User类里有个private Address address字段，但address是在别处 new 出来再 set 进来的，且生命周期不受User控制
为什么 IDE 或静态分析工具几乎无法自动识别这三种关系？
因为 Java 没有语法标记——final 字段、私有构造、无 setter 都只是线索，不是铁证。JVM 运行时更不会记录“这个引用算不算组合”。
- 工具只能检测强提示：比如字段是
private final且只在构造器中赋值，大概率是组合；但如果用了反射或字节码增强，连这点都不可靠 - 聚合和关联在字节码层面完全一样，区别只在业务语义和文档约定，所以团队必须统一建模规范，不能指望工具兜底
- 序列化/反序列化时尤其危险：
Car被 JSON 反序列化后，engine是新对象，但若原设计是组合，此时就意外降级为聚合了
什么时候该选组合而不是继承？别只盯着“is-a”和“has-a”
组合优先是原则，但真正卡住人的，往往是初始化顺序、测试隔离和 mock 成本。
立即学习“Java免费学习笔记（深入）”；
- 继承适合“行为契约稳定+子类不改变父类语义”，比如
ArrayList继承AbstractList - 组合更适合需要运行时替换、解耦测试或避免脆弱基类问题，比如用
PaymentStrategy接口组合进Order，而不是让Order继承AlipayOrder和WechatOrder - 容易踩的坑：组合引入太多小对象，导致堆内存碎片增多；或者过度拆分，让一个简单业务逻辑分散在 5 个类里，调试时得跳来跳去
Engine 持有文件句柄或网络连接，Car 就必须实现 AutoCloseable 并在 close() 中释放它——否则所谓“强生命周期绑定”只是纸面约定。 
