Go递归易栈溢出，应优先迭代：用slice模拟栈实现DFS，加深度限制，避免大对象分配；尾递归无效，复杂逻辑可考虑goroutine拆分。
递归函数容易栈溢出，Golang默认栈大小仅2MB
Go 的 goroutine 初始栈很小（2KB），按需增长，但单次递归调用仍会持续压栈。深度超过几千层就可能触发 runtime: goroutine stack exceeds 1000000000-byte limit 或直接 panic。这不是 Go 特别“脆弱”，而是它不鼓励无节制递归——比如遍历 10 万节点的链表或树时，func traverse(n *Node) { if n == nil { return }; traverse(n.Next) } 很容易崩。
实操建议：
- 优先评估是否真需要递归：树的深度优先遍历、图的拓扑排序等场景可改用显式栈 + 迭代
- 若必须递归，加深度限制参数并校验：
func walk(n *Node, depth int) error { if depth > 1000 { return errors.New("max depth exceeded") } ... } - 避免在递归中分配大对象（如切片、结构体），否则栈增长更快
用 slice 模拟栈实现迭代版 DFS，比递归更可控
Go 没有内置栈类型，但 []*Node 足够高效。把待处理节点压入 slice，循环 pop，替代函数调用栈。关键点不是“去掉递归”，而是把控制流从调用栈转移到堆上，从而规避栈限制。
示例：二叉树中序遍历迭代写法
立即学习“go语言免费学习笔记（深入）”；
func inorderIterative(root *TreeNode) []int {
var res []int
var stack []*TreeNode
curr := root
for curr != nil || len(stack) > 0 {
for curr != nil {
stack = append(stack, curr)
curr = curr.Left
}
curr = stack[len(stack)-1]
stack = stack[:len(stack)-1]
res = append(res, curr.Val)
curr = curr.Right
}
return res
}
注意：stack = stack[:len(stack)-1] 是 O(1) 出栈，不要用 stack = stack[1:]（会保留底层数组引用，影响 GC）。
尾递归在 Go 中无效，别指望编译器优化
Go 编译器不支持尾递归优化（TCO）。哪怕写成 return fib(n-1) + fib(n-2) 这种形式，也不会复用栈帧。更糟的是，像 return f(x) + 1 看似“尾部”，实际仍需保留当前栈帧来执行加法——Go 里真正能省栈的只有裸 return f(...)，且仅限直接调用，不支持间接或方法调用。
所以别为“是不是尾递归”纠结，直接重构为迭代更实在。如果逻辑复杂难转，考虑用 chan + goroutine 拆解（适合异步/分治场景），但要注意 channel 开销和调度延迟。
递归 vs 迭代的性能差异主要在内存分布与 GC 压力
表面上看，迭代用 []T 分配在堆上，递归用栈——好像迭代更重。但实际中，频繁小栈帧导致栈反复扩容、GC 扫描调用栈开销、以及逃逸分析失败引发的隐式堆分配，常让递归更慢。尤其是闭包捕获变量后递归，很容易触发变量逃逸到堆。
验证方式：
- 跑
go test -bench . -gcflags="-m"看关键变量是否逃逸 - 用
go tool trace观察 goroutine 阻塞与栈增长事件 - 对比
runtime.ReadMemStats中HeapAlloc和StackInuse变化趋势
真实项目里，只要递归深度不确定或可能超几百，就该默认选迭代。不是因为“迭代一定快”，而是它把不可控的栈行为，变成了可预估、可监控、可扩缩的堆行为。
