递归函数必须有明确且可达的终止条件，Go 不检查 base case，漏判或逻辑错误会导致栈溢出崩溃；阶乘函数需处理 n < 0 等边界，不能仅判断 n == 0。
Go 递归函数能用，但稍不留神就 panic，核心问题不是“会不会写”，而是“终止条件是否覆盖所有输入路径”和“指针访问前有没有判空”。
递归函数必须有明确且可达的终止条件
Go 不检查你有没有写 base case，它只管压栈。一旦条件漏判或逻辑反了，几层就触发 runtime: goroutine stack exceeds。这不是警告，是直接崩溃。
- 阶乘函数不能只写
if n == 0，得写if n ——否则传负数会无限递归 - 树遍历中，终止条件必须是
node == nil，而不是node.Left == nil && node.Right == nil（叶子节点才满足，中间节点直接跳过） - 用浮点数做递归控制变量极危险：
if x < 1e-9可能因精度误差永远不成立，改用整数计数或固定步长迭代 - 测试时从最简输入开始：
f(0)、f(1)、f(-1)都要跑一遍，确认不卡死也不 panic
指针类型递归必须先判空再访问字段
Go 没有空安全机制，node.Left 这种写法在 node == nil 时必然 panic：invalid memory address or nil pointer dereference。这不是运行时异常，是直接中断。
- 所有指针解引用前加
if node == nil { return }，别省这行 - 避免把判空和递归调用写在同一行，例如不要写
dfs(node.Left) + dfs(node.Right)；应拆成两步，每步前单独判空 - 返回指针的递归函数里，别返回局部变量地址：
return &x在多层递归中可能指向已释放栈帧 - 结构体嵌套深时（如 JSON 解析 AST），优先考虑用
[]interface{}或自定义栈结构手动模拟，而非深度递归
闭包内实现递归必须先声明后赋值
Go 编译器不允许在匿名函数字面量里直接引用尚未完成初始化的同名变量。这不是语法糖问题，是变量绑定顺序的硬性限制。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
var f func(int) int = func(i int) int { return f(i-1) }→ 编译失败，提示undefined: f - 正确写法：先
var f func(int) int声明，再f = func(i int) int { ... f(i-1) ... }赋值 - 这种写法本质是闭包捕获变量地址，若外层有循环（如
for _, v := range list { f = func() { use(v) } }），所有闭包会共享最后一个v值，需用临时变量锁住 - 生产环境更推荐具名函数：语义清晰、调试时堆栈可读、IDE 能跳转，没必要为“函数即值”牺牲可维护性
别信尾递归优化，Go 完全不支持
return fib(n-1) + fib(n-2) 看似“最后调用”，但加法在返回后执行，不是尾调用；Go 编译器（gc）也完全不优化任何递归形式。每层都占栈空间，5000 层以上基本不可靠。
- 真正尾递归形如
return f(n-1, acc + n)，但 Go 仍不复用栈帧 - 深度不确定的场景（如解析嵌套 JSON、遍历未知深度的目录树），必须用
for循环 + 显式栈（[]*TreeNode或[]interface{}）替代 - 标准库中
filepath.Walk、json.(*Decoder).input全部采用迭代实现，不是巧合，是经验沉淀 - 性能敏感场景（如高频调用的斐波那契），优先用记忆化或迭代重写，递归版仅适合教学或极浅层逻辑
递归最易被忽略的点不在“怎么调用”，而在“谁来保证每一步都落在安全路径上”——终止条件是否穷尽输入域、指针是否每次都被显式防护、闭包变量是否被意外共享。这些不是风格选择，是 Go 运行时强制要求的契约。
