Go中Composite模式通过接口抽象行为、结构体字段嵌入实现复用，关键在于叶子与容器对调用者透明；需避免nil panic、类型断言破坏多态、字段命名歧义、循环引用panic、递归栈溢出及粗粒度锁等问题。
Go 里没有继承，Composite 靠接口和嵌入实现
Go 不支持类继承，所以 Composite 模式不能靠“父类定义统一接口、子类分别实现”那一套。必须用接口抽象行为，再靠结构体字段嵌入（不是类型嵌入）来复用逻辑。关键不是“怎么写树”，而是“怎么让叶子和容器对调用者完全透明”。
常见错误是把 Component 设计成带指针的接口，导致 nil panic；或者在 Add 方法里不做类型检查，往叶子节点里强行加子节点却不报错，运行时才崩。
- 定义统一接口：
type Component interface { Operation() string; Add(c Component) } - 叶子节点只实现
Operation()，Add()方法直接 panic 或空实现（取决于业务是否允许防御性提示） - 容器节点用
children []Component字段，Add()就是append()，不校验传入值是否为容器——因为接口本就承诺了行为一致性 - 避免在接口方法里做
if c, ok := component.(*Container)类型断言，这会破坏多态，说明设计已偏离Composite原意
TreeNode 结构体要不要导出？字段命名怎么避坑
如果树结构要被外部包使用，TreeNode 类型必须导出（首字母大写），但内部字段如 children 最好不导出（小写），强制走 Add() / Remove() 等方法操作，否则用户直接改切片会绕过逻辑约束。
容易踩的坑是字段名用 Childs 或 SubNodes 这类模糊词，导致和 Parent 字段语义不一致；或把 Value 设为 interface{}，后续类型断言泛滥，失去静态检查优势。
立即学习“go语言免费学习笔记（深入）”；
- 推荐字段名：
Value（具体类型，如string或自定义NodeData）、children（小写，私有）、parent（可选，用于向上遍历） - 如果需要快速查子节点，别在
Add()里做 map 索引——除非明确需要 O(1) 查找，否则切片 + 线性 scan 更符合 Go 的简单哲学 - 不要给
TreeNode加json:"-"标签后又忘了在MarshalJSON方法里手动处理循环引用（父子双向指针），会导致json.Marshalpanic
递归遍历树时栈溢出？用 for + 切片模拟栈更稳
深度超过几千层的树，纯递归遍历（比如 Walk(c *TreeNode)）容易触发 goroutine 栈溢出，尤其在默认栈大小受限的环境（如某些容器或嵌入式场景）。Go 不支持尾递归优化，所以得主动换思路。
这不是性能问题，是可靠性问题：你无法预判用户构造的树有多深，而崩溃比慢更不可接受。
- 把递归改成迭代：用
[]*TreeNode当栈，push子节点，pop处理，显式控制深度 - 如果需保留访问顺序（如前序/后序），在 push 时注意子节点入栈顺序（后序需 reverse）
- 避免在迭代中频繁
make([]Component, 0, 16)——复用切片或传入预分配的 slice 能减少 GC 压力 - 错误现象示例：
runtime: goroutine stack exceeds 1000000000-byte limit，这时别调大 GOGC，先改遍历逻辑
并发安全的树操作：别锁整棵树，按需加锁节点
多个 goroutine 同时调用 Add() 或修改不同子树时，锁整棵树（比如用 sync.RWMutex 包裹根节点）会严重拖慢吞吐。Go 的惯用法是“最小粒度锁”，即每个节点自带锁，操作子树时只锁路径上的节点。
但要注意：锁粒度太细可能引发死锁，比如两个 goroutine 分别按 A→B 和 B→A 顺序加锁。
- 推荐做法：只在
Add()/Remove()时锁当前节点（mu.Lock()），读操作（如Operation()）若不修改状态，通常无需锁 - 如果真要并发修改同一子树，用
sync.Once初始化子树锁，或用sync.Map管理子节点映射（但会丢失顺序） - 绝对不要在持有节点锁时调用用户传入的回调函数——万一回调里又去加锁别的节点，死锁几乎必然发生
树形结构的复杂点不在构建，而在边界控制：谁负责释放内存（Go 有 GC，但循环引用仍要小心）、谁校验层级合法性（比如不允许叶子节点有子节点）、以及当接口方法被意外实现时，如何不让误用穿透到运行时才暴露。这些没法靠语法挡住，得靠文档 + 单测 + 接口方法的防御性返回（比如 Add() 返回 error）来兜底。
