组合模式在Go中通过接口+嵌入+递归实现，核心是统一处理叶子与容器：定义Component接口，Leaf和Composite分别实现，Composite的children切片存Component接口类型，Add方法接收Component参数以支持递归结构。
组合模式的核心判断：是否需要统一处理叶子与容器
Go 语言没有类继承，也不支持抽象类或接口强制实现，所以「组合模式」在 Go 中不是靠继承树模拟，而是靠接口 + 嵌入（embedding）+ 递归调用来达成行为一致。关键看你的业务里有没有这样的需求：Component 接口要同时被 Leaf（如文件）和 Composite（如目录）实现，并且上层代码能不区分类型地调用 Operation() 或 GetSize() 这类方法。
定义统一接口并让结构体实现它
必须先定义一个接口，把所有需要统一调用的行为收进来。注意：Go 接口是隐式实现的，只要结构体有对应签名的方法，就自动满足接口。不要试图用空结构体或“基类”做中间层——没用，还增加理解成本。
常见错误是把 Composite 的子节点切片类型设为 []*Component，但 Component 是接口名，不能直接作为指针类型声明切片元素。正确做法是让子节点切片存具体类型指针，再通过接口方法暴露统一行为。
-
Component接口只声明行为，不包含数据字段 -
Leaf和Composite各自管理自己的状态（比如名字、大小、子项） -
Composite的Add()方法接收Component类型参数，这样既能加Leaf也能加另一个Composite
type Component interface {
GetName() string
GetSize() int
Print(indent string)
}
type Leaf struct {
name string
size int
}
func (l *Leaf) GetName() string { return l.name }
func (l *Leaf) GetSize() int { return l.size }
func (l *Leaf) Print(indent string) {
println(indent + "? " + l.name + " (" + string(rune(l.size+'0')) + ")")
}
type Composite struct {
name string
children []Component // 注意：这里不是 []*Component
}
func (c *Composite) GetName() string { return c.name }
func (c *Composite) GetSize() int {
total := 0
for _, child := range c.children {
total += child.GetSize()
}
return total
}
func (c *Composite) Add(child Component) {
c.children = append(c.children, child)
}
func (c *Composite) Print(indent string) {
println(indent + "? " + c.name)
for _, child := range c.children {
child.Print(indent + " ")
}
}
构建对象树时避免循环引用和 nil panic
Go 没有构造函数语法糖，初始化 Composite 时容易忘记初始化 children 切片，导致后续 Add() 触发 panic: append to nil slice。另外，如果允许把父节点加进子节点列表（比如误传 composite.Add(composite)），会导致无限递归打印或栈溢出。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 总是用
&Composite{name: "root", children: make([]Component, 0)}初始化，别省略children - 在
Add()中可加简单检查，比如禁止添加自身（if child == c），但要注意 Go 中接口相等性比较需谨慎——建议只对指针类型做==判断，且仅限调试阶段 - 测试时用小规模树（1–2 层）验证
Print()和GetSize()是否符合预期，避免一上来就建 10 层嵌套后才发现递归逻辑错位
什么时候不该用组合模式
如果你的“叶子”和“容器”之间几乎没有共用行为（比如一个只读，一个只写），或者树深度固定且极浅（比如只有两级：Group → Item），强行套组合模式反而让代码更难读。Go 更倾向用简单结构体 + 明确函数分发，而不是模拟 OOP 的模式样板。
典型反例：用 Composite 包裹 HTTP handler 链、用组合模式实现配置解析器。这些场景更适合函数式组合（func(http.Handler) http.Handler）或结构体字段嵌入，而非运行时多态树形结构。
真正适合的地方是：文件系统抽象、UI 组件树（Button/Panel/Window）、权限节点（Role → Permission 或 Role → Role）、AST 节点遍历——它们天然具有“统一操作 + 递归展开”的特征。
