Golang组合模式(Composite)_统一处理整体与部分的树形结构

Go中用struct嵌套实现Composite模式需定义Component接口，容器节点以[]Component字段存储子节点，而非嵌套*Composite指针以避免循环依赖；叶子节点和容器节点均实现Component接口，容器在Operation()中遍历调用子节点Operation()。

Go 里怎么用 struct 嵌套实现 Composite？别直接嵌指针

Composite 模式在 Go 里不是靠接口继承，而是靠字段组合 + 接口统一行为。关键点是：叶子节点和容器节点都实现同一个 Component 接口，但容器节点内部用 slice 存其他 Component，而不是直接嵌 *Composite 类型——否则类型循环依赖。

• 错误写法：type Composite struct { children []*Composite } → 编译报错 invalid recursive type Composite
• 正确做法：定义 type Component interface { Operation() }，然后 Composite 的 children 字段是 []Component
• 叶子节点（如 Leaf）只实现 Operation()；容器节点除了实现 Operation()，还要遍历 children 调用各自 Operation()
• 注意：[]Component 存的是接口值，底层可能是 *Leaf 或 *Composite，运行时动态调用，没反射开销

为什么不能用 embed 做 Composite？embed 是静态的

embed 是编译期把文件内容塞进二进制，和运行时树形结构完全无关。有人看到 “组合” 就想用 type Composite struct { embed Component }，这是概念混淆。

• embed 只支持 struct 和未导出字段，不能 embed 接口
• 即使强行嵌了个 struct，它也不带子节点管理逻辑，没法 Add/Remove/Traverse
• Composite 的核心是“能加子节点、能递归操作”，这必须靠显式字段（如 children []Component）+ 方法实现
• 真正该用 embed 的地方是共享字段或方法集（比如日志字段、ID 字段），不是替代 Composite 结构

遍历树时 panic: runtime error: invalid memory address？检查 nil 指针

常见错误是往 children 里 append 了 nil 的 Component，或者初始化时忘了给 slice 分配空间，导致后续 range 出 panic。

• 错误示例：var c Composite; c.Add(nil) → c.children 是 nil slice，append(c.children, nil) 后仍是 nil，range 时 panic
• 安全写法：声明时初始化 children：children: make([]Component, 0)
• Add 方法里加判空：if comp != nil { c.children = append(c.children, comp) }
• 遍历前不假设非空：for _, ch := range c.children { if ch != nil { ch.Operation() } }

性能敏感场景下，避免 interface{} 和 reflect

有人想用 interface{} 存任意类型再反射调用，或者用 map[string]interface{} 模拟树节点——这完全背离 Go 的 Composite 实践，也失去类型安全和性能优势。

• Go 的 Composite 靠的是编译期确定的接口方法集，调用是直接跳转，无反射成本
• 用 interface{} + reflect.Value.Call，每次调用慢 10–100 倍，且无法静态检查方法是否存在
• 如果真要泛型化（Go 1.18+），应使用约束接口：type Node[T any] struct { children []Node[T] }，但注意这不能替代 Component 接口的多态能力，通常还是推荐接口方式

Composite 真正难的不是写结构，而是想清楚哪些行为该上提成接口方法、哪些该保留在具体类型里——比如 Add 和 Remove 通常只属于容器，叶子节点不该有；但 Operation 和 Accept(visitor) 这类访问行为必须统一。这点容易一开始设计就混在一起。