应看runtime.ReadMemStats().StackInuse是否持续上涨，而非NumGoroutine()；前者涨说明栈内存被新分配goroutine占用未释放，后者可能稳定——短命goroutine深递归仍会吃栈内存。
pprof 里 runtime.morestack 占比高，怎么确认是栈扩容不是 goroutine 泄漏
看 runtime.ReadMemStats().StackInuse，不是看 NumGoroutine()。前者持续上涨说明栈内存被新分配的 goroutine 占用且没释放；后者可能稳定甚至下降——短命 goroutine 深递归照样吃栈内存。启动时加 GODEBUG=gctrace=1，如果频繁打印 stack growth，基本就是小 goroutine 扛着大局部变量在跑。
用 pprof 定位栈扩容热点函数
执行：
go tool pprof -http=:8080 'http://localhost:6060/debug/pprof/heap?gc=1'然后在 Web 界面里运行：
top -cum -focus=morestack如果调用链大量呈现
walk → runtime.morestack → runtime.newstack，就不是堆分配问题，而是栈帧过大或递归过深触发了连续扩容。
- 注意：必须带
?gc=1参数，否则采样会混入瞬时垃圾，掩盖真实栈增长模式 -
runtime.morestack高占比 ≠ 栈快溢出，而是“已多次扩容”的证据，说明该路径存在持续压栈行为 - 火焰图中若某函数入口附近密集出现
runtime.morestack调用，大概率是该函数栈帧本身超限（比如声明了var buf [4096]byte）
逃逸分析误判如何间接导致栈扩容
编译器逃逸分析失败时，不会把变量送堆，反而会保守扩大栈帧预留空间。例如：&buf[0] 后传参给另一个函数，若编译器无法证明指针不越界，就可能让整个 buf 留在栈上但多留几百字节缓冲——这直接抬高单次调用所需栈空间，更容易触达 stackguard0。
- 用
go build -gcflags="-m -l"检查变量是否被标记为escapes to heap；没逃逸却仍栈涨，重点查指针运算、闭包捕获、接口赋值等边界场景 -
stackguard0不是水位线，它离当前SP约 8KB，是编译器预设的安全缓冲区；落到它下面，意味着“下个函数很可能放不下”，不是“只剩 8KB” - WASM 目标下
_StackMin可能只有 1KB，stackguard0缓冲更薄，本地测试通过不代表部署不出问题
递归函数里 defer 套大数组，为什么容易二次扩容
递归函数每层返回前执行 defer，而 defer 函数体内再声明大数组（如 var buf [4096]byte），会导致该 defer 执行时再次触发栈检查——此时栈已接近上限，stackguard0 再次命中，触发第二次 runtime.morestack。
立即学习“go语言免费学习笔记（深入）”；
- 这不是递归深度的问题，而是“每层都额外压一个大帧”的叠加效应
- 这种二次扩容在 pprof 中表现为同一函数名下出现两个不同栈深度的
runtime.morestack调用点 - 真正难处理的不是“怎么扩容”，而是“为什么必须扩容”——局部变量逃逸不准、闭包捕获过大结构体、递归没设深度限制，这些才是根因
StackInuse 曲线、morestack 的 cum 时间、以及逃逸日志里那些没明说但实际抬高了栈帧的指针操作。 
