Go支持递归但无尾递归优化，必须设明确可达终止条件，否则易栈溢出panic；深度超5000层即危险，终止条件需覆盖所有输入分支。
Go 语言里写递归，不是“能不能”，而是“怎么写才不崩、不漏、不慢”。它支持递归，但不纵容随意递归。
递归函数必须有明确且可达的终止条件
没终止条件的递归，几层就 panic。错误信息通常是 runtime: goroutine stack exceeds 1000000000-byte limit 或直接 fatal error: stack overflow。Go 没有尾递归优化，每调用一层都压栈，通常深度超过 5000 就危险。
- 终止条件要覆盖所有输入分支：比如阶乘函数写
if n ，不能只写 <code>n == 0，否则传负数会无限递归 - 对指针或接口类型（如
*TreeNode），终止条件应是node == nil，而不是node.Left == nil这类中间状态 - 递归前先问自己：这个条件在任意合法输入下，是否一定能在有限步内达成？
闭包内递归必须先声明再赋值
Go 不允许在匿名函数字面量里直接引用还没初始化完的同名变量。下面这种写法会编译失败：
var factorial = func(n int) int {
if n <= 1 { return 1 }
return n * factorial(n-1) // ❌ undefined: factorial
}正确做法是拆成两步：
立即学习“go语言免费学习笔记（深入）”；
var factorial func(int) int
factorial = func(n int) int {
if n <= 1 { return 1 }
return n * factorial(n-1) // ✅ 合法：factorial 已声明，可寻址
}- 漏掉第一行
var factorial func(int) int，编译器直接报错 - 这种写法本质是闭包捕获变量地址，不是语法糖；生产代码更推荐直接写具名函数，语义清晰、调试方便
递归调用结果必须显式返回
常见错误：在分支中调用了递归函数，却忘了把它的返回值 return 出去。结果就是逻辑走到最后，统一返回默认零值（比如 false 或 0）。
例如二叉树查找：
func (t *Tree) Find(val int64) bool {
if t == nil { return false }
if t.Value == val { return true }
if val < t.Value {
t.Left.Find(val) // ❌ 忘了 return！这行结果被丢弃
} else {
t.Right.Find(val) // ❌ 同样没 return
}
return false
}修复很简单，加 return：
if val < t.Value {
return t.Left.Find(val) // ✅
} else {
return t.Right.Find(val) // ✅
}- 每个递归分支的出口都要确保有
return，不能依赖“最后统一 return” - IDE 静态检查（如 gopls）通常能标出这类遗漏，但别全靠它
深度不可控时优先用迭代替代递归
文件遍历、深层嵌套 JSON 解析、图的 DFS —— 这些场景一旦数据来自外部（比如用户上传的 JSON 或目录结构），递归极易爆栈。Go 标准库的 filepath.Walk 就是用迭代实现的。
- 用
[]*Node模拟栈，手动 push/pop，把控制流从栈内存移到堆内存 - 若必须保留递归接口，至少加深度参数校验：
if depth > 1000 { return errors.New("max recursion depth exceeded") } - 避免在递归体里分配大对象（如
make([]byte, 1024)），会加速栈耗尽
递归在 Go 里不是“高级技巧”，而是一个需要主动设防的操作——终止条件是否坚固、返回值是否透传、深度是否可控，三者缺一不可。稍有松懈，崩的不是逻辑，是整个 goroutine 的栈空间。
