Component接口必须定义所有操作（包括Add/Remove），因为Go接口要求所有实现类型都提供全部方法签名，否则编译失败；Leaf应返回明确错误而非panic或空实现，以保障调用方能静态识别行为差异。
Go 语言没有继承，所以 Composite 模式不能靠“父类抽象 + 子类实现”来组织结构；必须用接口 + 组合 + 运行时类型判断来模拟树形行为。
为什么 Component 接口必须定义所有操作（包括 Add/Remove）？
这是 Go 中模拟 Composite 的关键妥协点。不像 Java/C# 可以让叶子节点抛异常或空实现，Go 的接口要求所有实现类型都提供全部方法签名——否则编译不通过。
常见错误是只给 Composite 实现 Add，而让 Leaf 留空或 panic，结果调用方无法静态区分能否添加子节点。
-
Leaf的Add/Remove应该返回明确错误（如errors.New("leaf node does not support children")），而不是静默忽略 - 如果业务上严格禁止对叶子调用增删，可在调用前用
if c, ok := node.(CompositeNode); ok做类型断言，而非依赖接口统一行为 - 把
Add/Remove移到单独的Container接口中更清晰，但会增加使用者的类型判断负担
如何避免递归遍历时的无限循环或 panic？
Composite 树结构容易因误设父子引用、或共享子节点导致环状结构，Visit 或 Count 类方法一遇到环就会栈溢出或死循环。
立即学习“go语言免费学习笔记（深入）”；
- 在
Composite.Add中检查是否已存在该子节点（用指针比较或 ID 判重），防止重复添加同一对象 - 遍历函数应接受一个
map[uintptr]bool记录已访问节点地址，每次进入前检查是否见过：ptr := uintptr(unsafe.Pointer(node)) - 避免在
String()或JSON.Marshaler中隐式触发深度遍历——这常导致调试时意外 panic
Composite 和 Leaf 的内存布局与性能差异
Go 编译器对小结构体和接口值有优化，但 Composite 模式天然带来间接成本：每次调用 Operation() 都经过接口动态分发，且子节点切片会引发额外内存分配。
- 若叶子节点极多（如解析 AST 或配置树），考虑用
[]Component替代*[]Component，减少一层指针跳转 - 叶子节点尽量用值类型（如
type Leaf struct { Name string; Value int }），避免无谓堆分配 - 高频遍历场景下，可为
Composite提供Iter() Iterator方法，返回自定义迭代器，绕过接口调用开销
真正难的不是写出来，而是决定哪些操作该暴露给叶子、哪些只属于容器，以及在运行时如何安全地向下转型——Go 没有继承链，所有“向上转型”都是接口赋值，“向下转型”全靠 type switch 或断言，稍不注意就漏掉分支或 panic。
