Go语言无传统栈溢出panic，因goroutine栈动态伸缩；深度递归会导致内存耗尽、OOM或调度卡死，需通过pprof分析StackInuse、morestack调用链及goleak检测goroutine泄漏来定位栈失控增长。
Go 语言中不会发生传统意义上的“goroutine 栈溢出”错误（如 panic: runtime error: stack overflow），因为每个 goroutine 的栈是动态伸缩的；但深度递归仍会导致内存耗尽、OOM 或调度卡死，需按实际现象排查，而非等待栈溢出 panic。
为什么 runtime.GOMAXPROCS 和 go tool trace 都看不到栈溢出信号
Go 运行时为每个 goroutine 分配初始栈（通常 2KB），并在需要时自动扩容（最大可达几 MB）。它不设固定栈上限，也不在栈满时 panic —— 而是持续分配新内存页。所以你永远不会看到类似 C 的 stack overflow 错误，但会观察到：
• 进程 RSS 内存持续上涨
• runtime.ReadMemStats 中 StackInuse 字段飙升
• pprof -alloc_space 显示大量栈内存来自 runtime.morestack 或 runtime.newstack
• 程序变慢甚至卡住（GC 压力剧增或 OS OOM killer 干预）
这意味着：检测重点不是“栈是否溢出”，而是“栈是否失控增长”。
用 pprof 定位异常栈内存消耗
直接抓取栈内存分配热点，比看 goroutine 数量更准：
• 启动时注册 pprof： import _ "net/http/pprof"，然后 http.ListenAndServe(":6060", nil)
• 运行可疑代码后，执行：go tool pprof http://localhost:6060/debug/pprof/heap
• 在交互式 pprof 中输入：top -cum -focus=morestack 或 top -cum -focus=newstack
• 若输出中大量显示 walkRecursive → runtime.morestack → runtime.newstack，基本可断定是递归导致栈反复扩容
• 补充验证：用 go tool pprof -alloc_space 替代 -inuse_space，能暴露历史累计栈分配量，对短命但深递归的 goroutine 更敏感
递归转迭代时容易忽略的 channel 边界条件
把 walkRecursive 改成迭代版，若用 channel 模拟调用栈，极易引入 goroutine 泄漏，反而掩盖栈问题：
• 错误写法：ch := make(chan *Node) 后只 go func() { for n := range ch { ... } }()，但忘记关闭 ch
• 结果：goroutine 永久阻塞在 range ch，栈虽小，但数量膨胀后同样吃内存
• 正确做法：显式控制生命周期，例如用 sync.WaitGroup + close(ch)，或更稳妥地改用切片模拟栈：stack := []*Node{root}，避免任何 goroutine 启动
• 关键区别：迭代本身不解决栈问题，但若引入并发，就叠加了 goroutine 泄漏风险 —— 这类问题常被误判为“栈溢出”，实则是两个独立缺陷交织
测试阶段用 goleak 拦截泄漏型递归残留
单元测试里跑深度递归逻辑，若未清理干净，可能让 goroutine 残留到下一个测试用例，干扰结果：
• 在 TestMain 中使用 goleak.VerifyTestMain(m)，全局拦截测试前后 goroutine 差异
• 若测试中启动了递归 goroutine（比如监听超时 channel 的后台任务），必须确保它收到 ctx.Done() 后真正退出，否则 goleak 会报：found unexpected goroutines: [chan receive]
• 注意：goleak 不检测栈大小，但它能揪出因递归逻辑没退出而长期存活的 goroutine —— 这些 goroutine 往往就是栈持续扩张的源头
• 实际案例：一个 func watch(ctx context.Context) { for { select { case 若 ctx 未传入或未 cancel，就会泄漏，且其栈虽小，但每秒新建 timer+goroutine，最终拖垮进程
真正难处理的不是“栈满了报错”，而是“栈悄悄长到 50MB 还不死”，此时 pprof 的 runtime.morestack 调用链和 goleak 报出的残留 goroutine，才是最该盯紧的两个信号。别等 OOM 才行动。
