用 json.Unmarshal 直接解析嵌套结构会 panic
Go 的 json.Unmarshal 要求目标结构体字段类型与 JSON 值严格匹配，一旦遇到同名字段在不同层级有不同数据类型（比如有时是对象，有时是数组），就会报 json: cannot unmarshal object into Go struct field。这不是配置问题，是类型系统硬约束。
常见于 API 返回的“不规范” JSON：比如 "children" 字段在叶子节点是 null，中间节点是数组，根节点又可能是对象——这种动态形态无法用单一 struct 描述。
- 别试图用
interface{}+ 类型断言兜底所有分支，代码会迅速变成嵌套if v, ok := x.(map[string]interface{}); ok { ... }套娃 - 优先考虑组合：把“能确定的部分”定义为结构体，把“可能变化的部分”交给接口或自定义类型处理
- 如果必须支持任意嵌套，用
json.RawMessage延迟解析，只在真正需要时再解一次
用 json.RawMessage 实现按需递归解析
json.RawMessage 是字节切片的包装类型，跳过反序列化阶段，把原始 JSON 数据暂存下来。它不消耗 CPU、不触发类型检查，是处理动态树结构最轻量的锚点。
典型场景：解析一个带 "type" 字段标识节点类型的树，比如 AST 或配置规则树，每个 type 对应不同子结构。
立即学习“go语言免费学习笔记（深入）”；
- 把不确定的子节点字段声明为
Children json.RawMessage，不是interface{}也不是[]Node - 递归函数接收
json.RawMessage，先用json.Unmarshal尝试解析成map[string]interface{}判断是否存在"type"，再决定走哪个分支 - 注意：多次调用
json.Unmarshal在同一段json.RawMessage上没问题，但别把它当成可重复读取的流——它是只读字节切片，无状态
type Node struct {
Type string `json:"type"`
Value string `json:"value,omitempty"`
Children json.RawMessage `json:"children,omitempty`
}
递归函数里怎么避免无限循环和栈溢出
JSON 树深度不可控时，递归函数容易爆栈，尤其在默认 goroutine 栈只有 2KB 的情况下。这不是逻辑错误，是资源边界问题。
关键不是“能不能递归”，而是“谁来控制深度”和“有没有退路”。
- 永远给递归函数加深度参数，比如
func parseNode(data json.RawMessage, depth int) (Node, error)，并在入口处设上限（如if depth > 100 { return Node{}, errors.New("max depth exceeded") }） - 不要依赖 defer 清理资源来防爆栈——defer 在函数返回时才执行，栈已崩了就来不及
- 如果树特别宽（单层几百个 children），用 for 循环处理子节点比递归更安全；深度深才用递归，宽度大就用迭代+显式栈
-
json.RawMessage本身不增加栈开销，但每次json.Unmarshal都会分配新 map/slice，深度大时 GC 压力明显
组合模式下怎么让不同类型节点共享行为
当树里有 Text、Container、List 多种节点，又都想支持 Render() 或 Validate()，靠继承不现实（Go 没继承），靠每个 struct 写一遍方法太重复。
核心是把“行为”抽成函数类型或接口，再通过字段组合注入，而不是靠结构体嵌套模拟 OOP。
- 定义统一接口如
type Renderable interface { Render() string }，让各节点类型分别实现，不强求共用字段 - 如果多个节点共用一段渲染逻辑（比如都需缩进），写一个独立函数
func indent(s string, level int) string，在各自Render()里调用，而非塞进某个基类 - 避免为了“统一”而强行设计泛型约束——比如
func Walk[T Renderable](root T)，实际中节点类型差异大，约束反而卡住扩展 - 组合优于继承的实操体现：一个
Containerstruct 可以包含Header *Text和Items []Renderable，不需要它们有共同父类型
json.RawMessage 就是那个“先存着”的开关，按需递归才是稳住不崩的关键。 
