该用组合模式当File和Directory需统一支持getSize()等操作且调用方无需类型判断；Go中通过接口定义行为、叶子与容器各自实现（容器递归委托）、避免嵌入以防语义污染。
什么时候该用组合模式而不是嵌套结构
组合模式的核心价值不是“能画出树”，而是让叶子节点和容器节点对客户端暴露统一接口。如果你的业务里 File 和 Directory 都要支持 getSize()、getName()、accept(visitor) 这类操作，且调用方不想每次先 if node.IsDir() { ... } 再分支处理，那就该用组合模式。
常见误用是强行套用：比如只有两层结构、节点类型固定、增删极少——这时直接用 map[string]*Node 或嵌套 struct 更轻量。
Go 里怎么实现 Component 接口的统一性
Go 没有抽象类，靠接口 + 组合实现“透明组合”。关键点在于：所有节点（叶子和容器）都实现同一组方法，而容器内部用切片存子节点，并在方法中递归委托。
-
Component接口只定义行为，不带字段；例如：type Component interface { GetName() string GetSize() int64 Add(child Component) Remove(child Component) GetChildren() []Component } -
File实现全部方法，但Add/Remove/GetChildren直接 panic 或返回空/零值（或按需用 error 替代 panic） -
Directory用children []Component字段，Add就是append，GetSize遍历累加子节点GetSize()
为什么 Directory 不该 embed File，而要用组合
嵌入（embedding）会把 File 的方法提升到 Directory 上，导致语义污染：一个目录对象能被当成文件调用 ReadContent()，这违背了组合模式“统一接口但职责分离”的本意。
立即学习“go语言免费学习笔记（深入）”；
正确做法是两者都独立实现 Component，Directory 内部只持有 children []Component，不继承、不嵌入任何具体节点类型。
- 避免用
type Directory struct { File }—— 这会让Directory“看起来像文件” - 不要为复用逻辑提取公共 struct，比如
BaseNode；Go 的接口组合已足够，额外基类反而增加耦合 - 如果多个节点共用字段（如
name），可用匿名字段name string，但绝不共享行为逻辑
遍历和 Visitor 模式怎么配合才不崩
组合模式常搭配 Visitor 实现解耦遍历逻辑。Go 中要注意：Visitor 方法签名必须覆盖所有具体节点类型，否则运行时类型断言失败。
典型错误是写一个 VisitFile(*File) 却忘了 VisitDirectory(*Directory)，结果在 node.Accept(v) 时 panic。
- Visitor 接口应定义
VisitFile(f *File)和VisitDirectory(d *Directory)两个方法 -
File.Accept(v Visitor)调用v.VisitFile(f)；Directory.Accept(v)先调自己，再遍历子节点调child.Accept(v) - 如果未来要加新节点类型（如
Symlink），必须同步更新 Visitor 接口和所有实现——这是 Go 缺乏泛型前的硬约束，没法绕过
真正容易被忽略的是循环引用风险：比如 Directory 的子节点意外指向自己父级，GetSize() 或 Accept() 会无限递归。上线前务必加深度限制或访问标记检查。
