go递归栈溢出无法recover，因发生在运行时层面；必须显式传depth参数并校验，或改用预分配容量的[]*node迭代模拟，禁用defer/recover、setmaxstack及goroutine伪解法。
Go 里递归函数栈溢出不是配置问题，而是设计预期——runtime: goroutine stack exceeds 1000000000-byte limit 这类 panic 无法 recover，也不能靠增大栈来根治。唯一可靠路径是：显式控制深度 + 迭代替代。
为什么 defer/recover 拦不住栈溢出
栈溢出发生在 Go 运行时层面，早于 Go 的 panic 机制。defer 和 recover 对这类错误完全无效，写再多包裹也没用。
- 实测：在递归入口加
defer func() { recover() }()，栈爆时照样 panic，无任何捕获 - 别把
runtime/debug.SetMaxStack当解药——它只影响新 goroutine 初始栈上限，和递归深度无关 - 真正该做的是：所有可能被用户输入或嵌套结构触发的递归函数，必须带
depth int参数
显式栈迭代怎么写才不翻车
用 []*Node 模拟调用栈比用 []interface{} 更安全，避免类型擦除带来的 GC 压力和间接访问开销。
- 预分配容量：
stack := make([]*TreeNode, 0, 1024)，减少扩容次数 - 入栈前检查：
if node != nil { stack = append(stack, node) }，防止空指针压栈后死循环 - 图遍历场景下，光判
len(stack) == 0不够，还得维护visited map[*Node]bool，否则会重复入栈 - 示例中序遍历的
curr = curr.Right后不校验是否为 nil，就直接进下一轮循环，容易漏节点
尾递归在 Go 里根本不存在
Go 编译器（截至 1.22）完全不支持尾调用优化（TCO）。所谓“尾递归写法”只是心理安慰，return dfs(node.Left) 和普通递归一样压栈，栈帧数不会少一个。
- 某些 Cgo 调用或内联失败时，尾调用甚至比普通递归更慢（多一次跳转）
- 别信网上“加
//go:noinline或@tailrec就能启用 TCO”的说法——Go 官方没这语法，gc 编译器也不认 - 真要省栈，只能手动展开逻辑，比如把“处理左/右/回退”状态编码进 struct 字段，配合 for 循环驱动
goroutine + channel 是伪解法
用 go f() 启动新 goroutine 模拟“迭代”，实际是把栈压力换成 goroutine 数量和调度开销，更容易 OOM。
- 每个 goroutine 至少占 2KB 栈 + 调度元数据，10 万次调用 ≈ 200MB 内存，而迭代版通常几 KB
-
channel收发有锁和内存屏障，在 DFS 这类强顺序场景下并发收益为零，反而增加 cache miss - 仅当子任务天然并行（如各子树独立计算哈希）且规模均衡时，才值得考虑 goroutine 分治
最容易被忽略的点：迭代改造时，“栈空”不等于“处理完”，尤其在图或带环结构中，忘了维护访问标记就会无限循环。深度限制不能只写在递归入口，也要在每次 append 前检查 len(stack) > maxDepth。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
