composite 应在需统一处理单个对象与对象组且对外暴露相同接口时使用，如文件系统或ui组件；若仅临时展示树形结构、嵌套简单或无需递归操作，则应避免使用。
什么时候该用 Composite 而不是继承或集合？
组合模式不是为了“看起来像树”而用，而是当你需要统一处理单个对象和一组对象，并且它们对外暴露相同接口时才真正必要。比如文件系统里的 File 和 Directory 都要支持 getSize()、list()；又比如 UI 组件中 Button 和 Panel 都要响应 render() 或 handleEvent()。
常见错误是：只有一两层嵌套、子对象类型固定、或者根本不需要递归操作——这时候硬套 Composite 反而让调用方多写一堆 instanceof 判断，还容易漏掉对叶子节点的空集合保护。
- 如果所有子对象都必须实现同一组方法，且调用方不关心当前是叶子还是容器，
Composite才值得引入 - 如果只是临时拼个树形结构用于展示（比如 JSON 输出），用
Map+List更轻量 - Java 中若已有现成类（如
javax.swing.JComponent）已内置组合能力，别重复造轮子
add() / remove() 放在抽象组件里安全吗？
不安全。标准写法里，只有容器类（Composite）才应该提供 add()、remove()、getChild() 这些修改结构的方法；叶子类（Leaf）如果也继承这些方法，要么抛异常，要么静默失败——这两者都会让调用方难以预料行为。
Java 没有办法在编译期阻止对叶子调用 add()，所以主流做法是：
立即学习“Java免费学习笔记（深入）”；
- 把
add()、remove()声明在具体容器类里，不在抽象基类Component中定义 - 或者在基类中定义但默认抛
UnsupportedOperationException，靠文档和测试约束使用方 - Spring 等框架里常见变体：用接口分离职责，比如
Component接口只含operation()，另设Container接口扩展管理方法
这样做能避免误操作，也更符合“接口隔离原则”。
递归遍历时怎么避免 StackOverflowError？
深度过大的树（比如 1000+ 层）用纯递归遍历 Component 树，很容易触发栈溢出。这不是模式本身的问题，而是 JVM 默认栈大小（通常 1MB 左右）撑不住深层调用。
实际项目中更稳妥的方式是：
- 改用显式栈（
Deque<component></component>）做 DFS，或队列做 BFS - 对超深节点加深度限制，超过阈值直接跳过或告警
- 如果业务允许，把树序列化后交由数据库（如 PostgreSQL 的
ltree）或图数据库处理，避开 JVM 栈限制
示例片段（非递归遍历）：
Deque<Component> stack = new ArrayDeque<>();
stack.push(root);
while (!stack.isEmpty()) {
Component c = stack.pop();
c.operation(); // 统一操作
if (c instanceof Composite) {
((Composite) c).getChildren().forEach(stack::push);
}
}
为什么 Composite 类常被误当成“万能容器”？
因为名字带“组合”，很多人以为它天然适合做配置聚合、DTO 封装甚至替代 Map<string object></string>。但它的核心契约只有一个：叶子与容器对客户端透明，且操作可递归向下传播。
一旦打破这个契约，问题就来了：
- 把
Composite当作通用数据载体，塞进不同语义的对象（比如同时放User和Order），会导致operation()含义模糊，后期无法维护 - 在 Spring Bean 中直接注入
Composite实例，却没考虑循环引用风险（A 包含 B，B 又引用 A） - 忽略线程安全：多个线程并发调用
add()和遍历，ArrayList存储子节点时可能抛ConcurrentModificationException
真正该警惕的是：你是否在用组合模式解决本该由策略模式、装饰器或简单聚合处理的问题。
树状结构本身不难建，难的是让每一层都清楚自己该响应什么、不该暴露什么。边界划不清，后面补救的成本远高于初期多写两个接口。
