组合模式在Go中用接口替代抽象基类，Leaf和Composite各自实现Component接口，Composite通过[]Component聚合子节点，避免嵌入式继承；需防循环引用、权衡接口性能与灵活性，并严格控制生命周期与并发安全。
组合模式在 Go 里没有“抽象基类”，得靠接口和嵌入
Go 没有继承体系，所以传统组合模式中 Component 抽象类那一套直接搬不过来。核心替代方案是：定义一个统一接口（比如 Component），所有叶子节点（Leaf）和容器节点（Composite）都实现它；容器节点通过字段嵌入子组件切片，并把公共逻辑（如 Add、Remove、Operation）封装在方法里。
常见错误是试图用结构体嵌入“模拟继承”，结果方法集不一致——比如在 Composite 中嵌入 Leaf，但 Leaf.Operation() 和 Composite.Operation() 行为完全不同，强行复用反而破坏语义。正确做法是两者各自实现接口，互不嵌入业务结构体。
-
Component接口只声明高层行为（如Execute()、Count()），不暴露内部结构 -
Composite内部用[]Component存子节点，不是[]*Leaf或[]*Composite - 避免在接口里暴露
Add/Remove给叶子节点——可定义CompositeComponent子接口，或让叶子节点的这些方法 panic（更明确）
什么时候该用组合模式？看这三点是否同时成立
组合模式不是炫技工具。它真正起作用的场景非常具体：你需要统一处理单个对象和“一群对象”（无论嵌套多深），且它们对外提供相同行为契约。典型例子包括文件系统遍历、UI 组件树渲染、配置项合并。
反例：只是想批量调用几个函数，用 for 循环就够了；或者子对象之间毫无行为共性（比如混着数据库连接和日志器放一起），硬套组合只会增加间接层。
立即学习“go语言免费学习笔记（深入）”；
- 存在天然的树形结构（如目录含子目录和文件）
- 上层逻辑需要透明地对任意层级节点执行相同操作（如
component.Render()） - 运行时才能确定结构深度与类型（不能靠静态类型枚举所有可能）
Composite 的 Add 方法必须检查循环引用
Go 不会自动检测父子循环引用，一旦 A.Add(B)，又在 B 的子节点里加回 A，后续遍历就会无限递归导致栈溢出。这不是理论风险——配置合并、动态 UI 构建等场景极易发生。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
最轻量的防御方式是在 Add 时做路径检查：递归向上查父链（需节点持有父指针），或用 map 记录已访问地址（适用于临时校验）。生产环境建议用后者，不侵入数据结构：
func (c *Composite) Add(child Component) {
visited := make(map[uintptr]bool)
if c.hasCycle(child, visited) {
panic("cycle detected in composite tree")
}
c.children = append(c.children, child)
}
func (c *Composite) hasCycle(node Component, visited map[uintptr]bool) bool {
ptr := uintptr(unsafe.Pointer(reflect.ValueOf(node).UnsafeAddr()))
if visited[ptr] {
return true
}
visited[ptr] = true
// 如果 node 是 Composite，递归检查其 children
if comp, ok := node.(interface{ Children() []Component }); ok {
for _, ch := range comp.Children() {
if c.hasCycle(ch, visited) {
return true
}
}
}
return false
}
注意：unsafe.Pointer 方式依赖运行时地址唯一性，在 GC 移动对象后可能失效；更健壮的做法是给每个节点加唯一 ID string 字段，由业务层保证不重复。
性能敏感场景慎用接口，考虑切片直传 + 函数式遍历
组合模式的接口调用有微小开销，更深的问题在于：每次调用 component.Execute() 都是一次动态分派，且树越深，调用栈越长。如果节点数达万级、每秒调用数百次（如游戏实体更新），这部分开销会累积。
替代思路是放弃统一接口，改用函数参数传递行为：
type Node struct {
Name string
Children []Node
}
func Walk(n Node, fn func(Node)) {
fn(n)
for _, ch := range n.Children {
Walk(ch, fn)
}
}
// 使用
Walk(root, func(n Node) {
if n.Name == "target" {
doSomething()
}
})
这种写法零接口、零分配（若 fn 是具名函数）、缓存友好。缺点是无法在运行时切换行为类型（比如从“渲染”切换到“序列化”），必须提前写死逻辑。所以它适合行为固定、性能压倒灵活性的场景。
组合模式真正的复杂点不在写法，而在于边界控制——谁负责生命周期（谁 new 谁 free）、并发安全（Add 是否要锁）、以及错误传播策略（某个子节点执行失败，是否中断整棵树）。这些细节不写进接口，却决定着模式能否落地。
