go递归易栈溢出因goroutine初始栈仅2kb，深度超千层即触发限制；应改用显式栈迭代，禁用尾递归幻想，慎用goroutine/channel伪迭代。
递归函数在 Go 中为什么会栈溢出
Go 的 goroutine 栈初始只有 2KB（64 位系统），递归深度稍大（比如 >1000 层）就容易触发 runtime: goroutine stack exceeds 1000000000-byte limit。这不是“写法错”，而是 Go 主动用栈大小做安全兜底——它不希望你靠增大栈来硬扛深递归。
- 常见场景：树的深度遍历（尤其不平衡二叉树）、解析嵌套 JSON/YAML、回溯算法（如 N 皇后）
- 别试
ulimit -s或改GODEBUG=stackguard=...，这些对 goroutine 栈无效 - Go 不提供类似 Python 的
sys.setrecursionlimit()，因为设计上就不鼓励深递归
用显式栈替代递归：以 DFS 为例
把调用栈搬进堆里，用 []interface{} 或更优的 []*Node 模拟，控制内存分配节奏。关键不是“去掉递归”，而是把“谁保存状态”从 runtime 切到你自己手上。
- 原始递归 DFS：
func dfs(node *Node) { if node == nil { return }; dfs(node.Left); dfs(node.Right) }—— 每次调用都压栈，深度即调用层数 - 迭代版核心逻辑：用
stack := []*Node{root}，循环 pop + push 子节点，len(stack)就是当前“模拟深度” - 注意指针 vs 值：用
*Node入栈，避免复制大结构体；若节点含 slice/map，更要小心逃逸分析
tail call 优化不存在，别信“尾递归就能省栈”
Go 编译器（截至 1.22）**完全不支持尾递归优化**。哪怕你写成 return dfs(node.Left)，栈帧照常增长。这是明确的编译器限制，不是配置或写法问题。
- 验证方式：在递归函数开头加
runtime.Stack(buf, false)，看输出栈帧数量是否随深度线性增加 - 某些 Cgo 调用或内联失败时，尾调用甚至可能比普通递归更慢（多一次函数地址跳转）
- 真要省栈，唯一可靠路径是：手动展开 + 状态机化（比如把“当前处理左子树/右子树/回退”编码进 struct 字段）
goroutine + channel 不是银弹，慎用于“伪迭代”
有人用 go dfs(node.Left) + channel 收集结果，以为能绕开栈限制——实际只是把栈压力转成 goroutine 数量和调度开销，更容易 OOM 或被调度器拖慢。
立即学习“go语言免费学习笔记（深入）”；
- 每启动一个 goroutine 至少消耗 2KB 栈 + 调度元数据，10 万节点 ≈ 200MB 内存，远超迭代版的几 KB
- channel 发送/接收有锁和内存屏障，深度优先场景下并发收益极低，反而增加 cache miss
- 只在天然并行的场景用 goroutine：比如每个子树独立计算哈希值，且子树规模均衡
