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