Go中栈溢出主因是递归过深或局部变量过多，而非初始栈小；初始栈2KB可动态扩容至1GB上限，超限即panic。
看 panic 日志里有没有重复函数名
Go 报 runtime: goroutine stack exceeds 1000000000-byte limit 时，堆栈里如果连续出现同一个函数名（比如 walkNode → walkNode → walkNode），基本就是深层递归没断。这不是偶然，是调用链被压扁后反复出现的铁证。
注意：别只扫一眼最顶上几行。用 strings.Count(panicBuf, "walkNode") 数一数出现次数，超过 200 次就极大概率是递归失控；500+ 基本可确认没设终止条件或深度防护。
- 常见陷阱：日志被截断、panic 被 recover 吞掉、HTTP handler 里 defer recover 掩盖了原始堆栈
- 解决办法：临时注释掉所有
recover()，让 panic 直接打到 stderr；或用runtime.Stack(buf, true)手动捕获全栈再打印
用 pprof 抓 morestack 调用热点
Go 不会在栈满时 panic，而是在扩容时调 runtime.morestack。所以真正要盯的是这个函数的调用频次和来源，而不是等 panic。
启动时加 import _ "net/http/pprof"，跑可疑逻辑后执行：
立即学习“go语言免费学习笔记（深入）”；
go tool pprof http://localhost:6060/debug/pprof/heap
进交互式界面后输：
top -cum -focus=morestack
如果输出里 walkRecursive 占前 3 行、且每行都带 runtime.morestack，说明它正在疯狂扩容栈。
- 更准的验证方式：换用
go tool pprof -alloc_space http://.../heap，看累计栈分配量——短命但深递归的 goroutine 在这里更容易暴露 - 别只看
/goroutine，那个只告诉你有多少协程，不告诉你栈在哪儿炸
检查递归函数是否漏了空指针或边界校验
很多“深层递归”根本不是数据深，而是逻辑漏洞导致无限循环。比如遍历树时写 if node.Left != nil { walk(node.Left) }，但忘了 node 本身可能为 nil，结果 walk(nil) 进入无出口分支。
重点查三处：
- 所有递归入口前有没有
if node == nil或if n 这类守卫 - 递归参数是否可能“跳过”所有终止条件（例如传入
n = -10，但守卫只写了n == 0） - 结构体字段访问前有没有判空（
node.Children为 nil 时直接 range 会 panic，但有时被 recover 捕获后转成静默递归）
用 go tool compile -S 看单函数栈帧大小
栈溢出不一定是因为调用深，也可能是单层函数分配了超大局部变量。比如 var buf [1048576]byte 直接压栈，2KB 初始栈瞬间崩。
运行：
go tool compile -S your_file.go | grep -A5 "TEXT.*walkNode"
关注输出里的 subq $X, %rsp 行（X 就是该函数预估栈帧字节数）。如果 X > 8192，就得警惕。
-
var data [1024]byte是栈分配；data := make([]byte, 1024)是堆分配 —— 差别巨大 - 编译器对闭包、defer、recover 的栈开销不透明，复杂函数建议拆分
recover 吞掉 panic、又没打全栈的日志，或者用 channel 模拟递归但忘了 close 导致 goroutine 泄漏，最后被误报成“栈溢出”。这类问题得靠 ?debug=2 和 StackInuse 双验证，不能只信错误字符串。 
