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) 这类访问行为必须统一。这点容易一开始设计就混在一起。
