17370845950

Go中组合模式典型误用是硬套UML继承结构，正确做法是用结构体嵌入+接口统一行为：定义Node接口和baseNode基类，各节点内嵌baseNode并按需实现Add等方法，避免类型断言、空指针和内存泄漏。

什么是组合模式在 Go 中的典型误用场景

很多人一上来就定义 Component 接口，再写 Leaf 和 Composite 两个结构体，结果发现增删节点时类型断言频繁、遍历逻辑重复、空指针 panic 频发——这往往是因为没抓住 Go 的组合本质：它不靠继承模拟树，而靠结构体嵌入 + 接口统一行为。

Go 没有子类继承，硬套经典组合模式 UML 图只会让代码变重。真正轻量的做法是：用一个结构体同时承载“自身数据”和“子节点切片”，再通过接口暴露统一的 Add、Remove、Accept 等方法。

用 embed 实现可嵌入的树节点基类

Go 的 embed 不适用于运行时对象组合，这里实际要用的是结构体字段嵌入（embedding），不是 //go:embed。常见错误是把 children 声明为 []*Component，导致无法直接调用子节点特有方法；或者用 interface{} 存子节点，失去类型安全。

• children 应声明为 []Node，其中 Node 是接口，所有节点都实现它
• 每个具体节点结构体（如 FileNode、DirNode）内嵌一个匿名字段 baseNode，封装通用字段（name、parent、children）和基础方法
• baseNode 的 Add 方法应检查是否已存在同名节点，避免重复插入
• 删除时用 append(slice[:i], slice[i+1:]...) 而非 slice = append(slice[:i], slice[i+1:]...)，否则可能影响原切片底层数组

type Node interface {
    GetName() string
    GetParent() Node
    Add(child Node)
    Remove(child Node)
    Children() []Node
}

type baseNode struct {
    name     string
    parent   Node
    children []Node
}

func (b *baseNode) GetName() string { return b.name }
func (b *baseNode) GetParent() Node { return b.parent }

func (b *baseNode) Add(child Node) {
    if child == nil {
        return
    }
    for _, c := range b.children {
        if c.GetName() == child.GetName() {
            return // 防重名
        }
    }
    child.setParent(b)
    b.children = append(b.children, child)
}

func (b *baseNode) Remove(child Node) {
    for i, c := range b.children {
        if c == child {
            b.children = append(b.children[:i], b.children[i+1:]...)
            child.setParent(nil)
            return
        }
    }
}

func (b *baseNode) Children() []Node { return b.children }

func (b *baseNode) setParent(p Node) {
    b.parent = p
}

如何让叶子与容器节点共享同一接口但行为不同

关键不在“是否能加子节点”，而在“调用 Add 时是否允许”。比如 FileNode 应拒绝添加子节点，而 DirNode 允许——这不是靠运行时类型判断，而是靠各自实现的 Add 方法内部逻辑区分。

• FileNode 的 Add 方法可以 panic 或静默忽略，但更推荐返回 error（需修改接口签名）或记录 warn 日志
• 若需严格控制，可将 Add 拆成 TryAdd（返回 bool）或 AddOrError（返回 error），避免隐式失败
• 遍历整棵树时，统一调用 node.Children() 即可，无需提前 if _, ok := node.(*DirNode) 类型断言
• 注意：Children() 返回的是 []Node，不是具体类型切片，所以不能直接对返回值做 node.Children()[0].(*DirNode) 强转，除非你确定类型且做了安全检查

type FileNode struct {
    baseNode
    size int64
}

func NewFileNode(name string, size int64) *FileNode {
    return &FileNode{
        baseNode: baseNode{name: name},
        size:     size,
    }
}

// FileNode 不支持添加子节点
func (f *FileNode) Add(child Node) {
    // 可选：log.Warn("FileNode does not support children")
}

type DirNode struct {
    baseNode
    modified time.Time
}

func NewDirNode(name string) *DirNode {
    return &DirNode{
        baseNode: baseNode{name: name},
        modified: time.Now(),
    }
}

// DirNode 支持添加子节点
func (d *DirNode) Add(child Node) {
    d.baseNode.Add(child)
}

遍历与访问时容易忽略的循环引用与内存泄漏

当节点双向持有（child.parent = parent，parent.children = append(..., child)），GC 无法自动回收整棵子树——尤其在长期运行的服务中，反复构建又丢弃树结构，会导致内存缓慢上涨。

• 避免在 Remove 时只清空父节点的 children 列表，却忘了把子节点的 parent 设为 nil
• 如果树结构需要持久化或跨 goroutine 共享，考虑用弱引用（如 sync.Map 存 ID → Node 映射）替代强指针引用
• 调试时可用 runtime.ReadMemStats 对比前后堆分配，确认是否因未清空 parent 引用导致对象滞留
• 深度优先遍历递归过深可能触发栈溢出，生产环境建议改用显式栈（[]Node）实现迭代遍历

组合模式在 Go 里不是设计模式考题，而是管理嵌套资源（如配置树、权限节点、AST 表达式）的实用工具。它的复杂点从来不在“怎么画类图”，而在于“谁负责清理引用”和“错误该在哪一层暴露”。