递归结构转换必须显式处理nil指针、手动实现缓存、逐层类型断言、避免尾递归依赖，并设深度阈值防栈溢出。
递归结构转换必须显式处理 nil 指针
Go 中递归数据结构（比如树、嵌套 JSON、链表）在转换时最常 panic 的原因是 nil 指针解引用。例如对 nil 的 *TreeNode 调用 .Left 或访问字段，会直接崩溃，而不是返回默认值。
这不是语法错误，而是运行时陷阱——编译器不会报错，但一旦数据不完整（如空子树、缺失字段），转换逻辑就中断。
- 所有递归入口函数第一行必须做
if node == nil { return ... }判断 - 不要依赖“结构体零值”自动兜底：Go 的
struct{}不等于nil，但*T类型的零值就是nil - 从 JSON 反序列化来的嵌套结构，字段可能为
nil（尤其用了json.RawMessage或指针字段）
避免重复计算：用 map 缓存中间结果
像斐波那契或树路径求和这类问题，原始递归会指数级重复调用相同参数组合。Go 没有内置记忆化（memoization），必须手动加缓存。
缓存不是可选优化，而是防止超时的关键——fib(40) 原始递归要算上亿次，加缓存后只要 40 次。
立即学习“go语言免费学习笔记（深入）”；
- 缓存键通常用参数组合：如
fmt.Sprintf("%d-%s", depth, id)，但更推荐定义结构体并实现hash方法 - 缓存变量应放在递归函数外（闭包或结构体字段），否则每次递归都新建 map，起不到作用
- 注意并发安全：如果递归在 goroutine 中并行执行，要用
sync.Map或加锁
类型转换必须逐层显式声明
Go 的类型系统不允许隐式转换，递归结构中嵌套的 interface{}（比如 json.Unmarshal 返回值）或 any 必须一层层断言，不能跳过中间层级。
常见错误是写 v.(map[string]interface{})["children"].([]interface{})[0].(map[string]interface{}) 这种长链断言——任一环节失败就 panic，且无法区分是哪一层出问题。
- 每一步转换后立刻检查
ok：如if m, ok := v.(map[string]interface{}); !ok { return err } - 把转换逻辑拆成小函数，每个只负责一层，便于定位和测试
- 优先用结构体 +
json.Unmarshal替代interface{}解析，减少运行时断言
尾递归无法被 Go 编译器优化
Go 不支持尾递归优化（TCO）。即使你把递归写成尾调用形式，比如 return f(n-1, acc)，调用栈仍会持续增长。
这意味着深度超过几千层的递归（如极深的树、长链表）必然触发 stack overflow，不是性能差，而是直接 crash。
- 别指望改写成尾递归就能绕过栈限制——Go 语言规范明确不保证 TCO
- 真正可行的替代方案是：用切片模拟栈（迭代 DFS）、或用 channel + goroutine 拆分任务（但要注意 goroutine 泄漏）
- 生产环境处理未知深度结构时，建议设置硬性递归深度阈值，超限即返回错误，而不是靠 recover 捕获 panic
