Go语言没有运行时主动缩容机制：函数返回后栈内存不释放，仅goroutine退出时归还至stackpool或stackLarge缓存；runtime.Stack()显示栈范围变小仅为快照，反映栈指针回退而非真实缩容。
Go 语言中 goroutine 栈空间没有运行时主动收缩机制——函数返回后栈内存不会归还，直到 goroutine 彻底退出才释放。
为什么 runtime.Stack() 看起来“栈变小了”，但实际没缩容
调用 runtime.Stack() 输出的是一份当前栈帧快照，只反映此刻活跃的调用链长度和栈指针位置（sp），不体现底层分配的内存块是否被回收。即使你递归 100 层后全部返回，gp.stack.hi - gp.stack.lo 仍维持在最后一次扩容后的大小（比如 8KB），不会回落到初始 2KB。
常见误解是看到日志里地址范围收窄，就以为栈缩了——其实只是栈顶指针（sp）回退，而 g.stack.lo 和 g.stack.hi 这两个边界值在整个 goroutine 生命周期内只增不减。
goroutine 退出时的栈内存去向
当 goroutine 执行完毕并退出，它的栈内存不会直接返还操作系统，而是进入运行时两级缓存：
-
stackpool：用于复用 ≤ 32KB 的小栈（按 size class 分组），供后续新 goroutine 快速分配 -
stackLarge：管理 > 32KB 的大栈，由 GC 在内存压力大时决定是否整体释放回 OS
这意味着：短生命周期、高频创建/退出的 goroutine（如 HTTP handler）可能造成 stackpool 积压，表现为 RSS 内存居高不下，但 pprof heap profile 不会显示泄漏——因为这些内存属于 runtime 管理的栈池，不在堆上。
哪些操作看似“缩容”实则无效
以下做法无法触发栈收缩，且可能引入风险：
- 调用
debug.SetMaxStack：该函数早已被移除，任何尝试都会编译失败或静默忽略 - 用
unsafe手动修改g.stack字段：会导致 GC 扫描错乱、指针重写失败，触发fatal error: stack overflow或静默崩溃 - 在 defer 中显式清空大变量（如
buf = nil）：不影响栈帧已分配的空间，局部变量声明本身已计入栈需求，清空只影响堆对象引用
真正影响栈占用的是函数入口处编译器预估的帧大小，不是运行时值的变化。
如何避免栈内存堆积成问题
关键不是“怎么缩”，而是“别让它涨太多”：
- 避免在 hot path 函数里声明 >1KB 的局部数组（如
[2048]byte），改用make([]byte, 2048)分配到堆上 - 深度递归逻辑务必设深度上限，或改用显式栈（
slice模拟）+ 循环，绕过编译器帧大小预估 - 交叉编译目标（如 wasm）下
_StackMin可能为 1KB，测试必须用相同GOOS/GOARCH，否则线上容易意外触发频繁扩容 - 观察
GODEBUG=gctrace=1日志里的stackalloc和stackfree行数，若前者远多于后者，说明 goroutine 寿命过短、栈复用率低
最常被忽略的一点：goroutine 栈的“不可收缩”不是缺陷，而是设计取舍——它换来了栈指针重写的安全性与 GC 扫描的确定性。想省内存，优先控制 goroutine 数量和单次栈消耗，而不是期待它自动变小。
