组合模式应在需统一调用如getsize()或支持visitor且节点类型可能扩展时使用；否则嵌套struct更轻量；add/remove不应强加于叶子节点；directory不应embed file以避免语义污染和耦合。
组合模式在 Go 里不是“必须用接口+panic”的教条，而是当你需要对叶子和容器调用同一方法（比如 GetSize()、Accept()）且不想写 if node.IsDir() { ... } 分支时，才值得引入。
什么时候该用 Component 接口而不是嵌套 struct
常见误判是看到“树形结构”就上组合模式。但如果你的结构只有两层、节点类型固定（如 type Config struct { Sections []Section }）、增删极少，直接用嵌套 struct 更轻量——type Folder struct { Name string Files []File Folders []Folder } 就够了，它没有行为契约，但也没必要有。
真正需要 Component 接口的信号是：
- 客户端要统一调用
node.GetSize()，而File返回自身大小、Directory返回所有子节点大小之和 - 你要支持 Visitor 模式（比如导出为 JSON 或计算校验和），且不希望每次遍历都手动判断类型
- 未来可能新增第三种节点（如
Symlink或RemoteFile），它们也得能插进同一棵树里
Add() 和 Remove() 在叶子节点里怎么处理才不坑人
很多教程让 Leaf 对 Add() 直接 panic，这在测试或 CLI 工具里容易炸，而且掩盖了设计意图。更务实的做法是：
- 如果业务逻辑上绝对不允许向叶子添加子项，返回
errors.New("not supported")，让调用方显式处理错误 - 如果只是“当前不支持”，但未来可能支持（比如可配置的叶子节点），返回
nil并加注释说明语义 - 不要在接口里强制声明
Add()和Remove()—— 它们不是所有节点的共性行为；把这类操作收归到Composite类型的方法里，比如dir.AddChild(c Component)
接口越窄越安全：type Component interface { GetName() string GetSize() int64 Accept(v Visitor) } 比塞满增删方法的接口更易维护。
为什么 Directory 不该 embed File
嵌入 File 看似省代码，实则破坏语义边界：
-
Directory会意外获得File.ReadContent()方法，导致os.Open(dir)这类调用在编译期不报错，运行时才 panic - 字段名冲突：如果
File有name string，Directory也 embed 它，再加自己的name string，就会覆盖或歧义 - 耦合加重：一旦
File改了方法签名，所有 embed 它的类型都要跟着动
正确做法是两者都独立实现 Component，Directory 内部只存 children []Component，不共享字段、不继承行为。复用逻辑靠组合，不是靠嵌入。
Visitor 实现时最常漏掉的类型断言检查
Visitor 模式在 Go 中依赖类型断言，但很多人只写 VisitFile(*File)，忘了 VisitDirectory(*Directory)，结果在 node.Accept(v) 时 runtime panic。
安全写法是：
- Visitor 接口必须覆盖所有具体节点类型：
type Visitor interface { VisitFile(*File) VisitDirectory(*Directory) } - 在
Accept()方法里做完整分支：func (d *Directory) Accept(v Visitor) { v.VisitDirectory(d); for _, c := range d.children { c.Accept(v) } } - 如果节点类型多，考虑用
switch v := node.(type)配合default分支兜底，避免漏类型
接口方法少、类型明确、断言位置集中——这是 Go 里 Visitor 不崩的关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
