递归函数必须有明确且可达的终止条件，否则会无限调用导致栈溢出；go无尾递归优化，通常几千层即崩溃，需确保终止条件覆盖所有路径。

递归函数必须有明确的终止条件

没有终止条件的递归会无限调用，直到栈溢出，报错 runtime: goroutine stack exceeds 1000000000-byte limit 或直接 panic。Go 没有尾递归优化，每次调用都压栈，深度受限（通常几千层就崩）。

• 写递归前先问自己：什么情况下该停？这个条件是否一定能被到达？
• 常见错误是把终止条件写成 n == 1 却没处理 n ，导致负数输入时无限递归
• 对树/链表等结构递归时，终止条件通常是 node == nil，不是 node.Next == nil

避免在递归中意外修改共享状态

Go 是值传递，但切片、map、指针、channel 是引用语义。如果递归函数里修改了外部传入的 slice 或解引用了 *int，上层调用看到的值可能已变，逻辑错乱。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 需要“回溯”时（比如全排列、路径搜索），推荐在递归调用前拷贝状态，例如用 append([]int{}, path...) 而非直接传 path
• 不要在递归体里直接 append 到一个外部切片变量——它会被所有层级共享
• 若必须复用内存，显式做 defer 恢复，比如 path = path[:len(path)-1]

递归 vs 迭代：什么时候该换掉递归

Go 的函数调用开销比循环高，且栈空间有限。深度不确定或可能超过几百层时，优先考虑迭代 + 显式栈（[]*TreeNode）或队列。

• 文件系统遍历、深层嵌套 JSON 解析、图的 DFS —— 这些场景一旦数据不可控，递归极易爆栈
• filepath.Walk 内部用的是迭代，不是递归，就是出于这个原因
• 简单数学计算（如阶乘、斐波那契）可用递归练手，但生产代码建议用迭代，更稳也更快

闭包内递归要显式命名函数变量

Go 不支持匿名函数直接递归调用自己，因为 func() {} 没名字，内部无法引用自身。

• 正确写法是先声明函数变量，再赋值闭包：var fib func(int) int; fib = func(n int) int { ... return fib(n-1) + fib(n-2) }
• 漏掉 var fib func(int) int 这行，编译会报 undefined: fib
• 这种写法容易让新人困惑作用域，不如直接写具名函数清晰

递归本身不难，难的是想清楚“谁在变、谁该停、谁被共享”。尤其在并发或复杂数据结构里，多一层调用，就多一分状态失控的风险。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！