Go debug.SetMaxStack 怎样限制单个 goroutine 栈增长

排查 Go 服务递归失控时，runtime/debug.SetMaxStack 适合做最后一道“单个 goroutine 栈不能无限长”的边界。它接收字节数，返回设置前的旧上限；某个 goroutine 在后续扩栈时超过上限，进程会直接崩溃。这个 API 不是总内存限制，也不是线程数限制。

官方地址：https://pkg.go.dev/runtime/debug#SetMaxStack

先把“栈上限”与其他资源分开

一个 goroutine 的栈会按需增长。无限递归、异常的树遍历或错误的回调链，可能让同一个栈持续扩张。SetMaxStack 的作用是给这条增长设置硬上限，主要价值是限制失控递归的破坏范围。

它不回答三个常见问题：进程堆用了多少内存、垃圾回收多久发生一次、操作系统线程开了多少个。分别应查看 debug.SetMemoryLimit、debug.SetGCPercent 和 debug.SetMaxThreads。先判断资源类型，再选参数，排查会快很多。

在启动阶段设置，并正确理解返回值

如果确实要改变上限，建议在服务启动或测试子进程初始化阶段完成，避免不同业务路径各自修改全局运行时配置。示例只展示配置关系，不代表已经在本机运行：

package main

import (
    "log"
    "runtime/debug"
)

func configureStackLimit() {
    // 参数是字节数；这里把单个 goroutine 的后续栈增长上限设为 8 MiB。
    const limit = 8 

不要把 old 当成新配置，也不要在请求处理函数里反复调用。它是进程级运行时设置，调用位置应集中、可追踪。生产值不能照抄示例；过小会把正常的深调用链也变成进程级故障。

“只限制后续增长”决定了排查顺序

官方文档特别强调：SetMaxStack 只限制未来的栈增长。它不会把已经扩大的栈压回去，也不会替你终止可疑 goroutine。因此正确的排查重点是设置之后会不会继续扩栈，以及是什么调用路径触发了增长。

可以把设置动作放在可疑 goroutine 创建前，再用隔离进程测试递归深度或异常输入。不要在主服务里直接用故意触顶的代码验证，因为超过上限的结果是进程崩溃，而不是一个可以被 recover 捕获的普通业务错误。

上线前用清单避免把边界设错

回归时至少记录三件事：默认上限与自定义上限的差异、设置时机、以及异常输入下的调用深度。若测试需要触发边界，应让它运行在独立子进程中，避免测试进程和服务进程一起被带走。

常见问题

SetMaxStack 能防止所有 goroutine 总栈内存过大吗？

不能。它针对单个 goroutine；多个 goroutine 各自增长造成的总量，需要结合并发控制、内存限制和调用链治理。

超过 SetMaxStack 后能用 recover 继续服务吗？

不能按普通 panic 处理。官方语义是程序崩溃，所以应在隔离测试中验证阈值，并修复递归或输入边界。

调小上限会立刻释放已经使用的栈吗？

不会。它只影响后续增长，既有栈空间的回收不是这个 API 的职责。