go语言没有运行时栈缩容机制，仅在goroutine退出时将栈内存归还runtime缓存；栈扩容由编译器在函数入口插入cmp sp, stackguard0指令预判触发，差1字节即整栈搬家。
Go 语言里没有“栈缩容”这回事——runtime 不会在函数返回后回收栈内存，所谓“缩容”只发生在 goroutine 彻底退出时，且仅归还给内部缓存，不返还 OS。栈扩容也远非“按需增长”，而是靠编译器在函数入口插入 CMP SP, stackguard0 指令预判式触发，差 1 字节不够就整栈搬家。
为什么 var buf [4096]byte 一声明就 panic
这不是运行时检测到爆栈才反应，而是编译器静态计算出该函数帧至少需 ~4KB（数组 + 调用开销），而初始栈仅 2KB，剩余空间加安全水位线（stackguard0 约距栈顶 8KB）仍不够，调用前直接跳转 runtime.morestack；若此时无法分配新栈（如内存不足、或已接近 1GB 上限），就 fatal error: stack overflow。
-
buf大小必须 ≤ 当前栈剩余空间 − 函数调用开销（返回地址、寄存器保存等），否则不执行就失败 - 闭包捕获大结构体、
defer中声明大变量，同样被算入帧大小，容易被忽略 -
go tool compile -S main.go可查是否生成CALL runtime.morestack_noctxt，确认该函数参与栈检查
runtime.GOMAXPROCS 和 go tool trace 都看不到栈溢出信号
Go 不抛 panic: stack overflow，它会持续扩容直到失败——所以你看到的往往是进程 RSS 暴涨、GC 频繁、调度卡顿，或最终 runtime: out of memory。真正有用的信号是：
- 启动加
GODEBUG=gctrace=1，日志中出现stack growth: g[123] grew stack from 2048 to 4096 bytes -
go tool pprof http://localhost:6060/debug/pprof/heap后输入top -cum -focus=morestack，若大量命中递归函数链，就是栈失控 -
runtime.ReadMemStats对比前后StackInuse字段增量，比 CPU 占比更早暴露问题
递归改迭代时最易踩的坑：channel 泄漏掩盖栈问题
把深度递归改成 channel + goroutine 模拟调用栈，看似规避了栈压力，实则引入新风险：
- 未关闭
chan导致for range永久阻塞，goroutine 泄漏，数量膨胀后内存照样爆 - 每个新 goroutine 仍带 2KB 初始栈，1000 个并发就是 2MB 栈内存，且无法复用
- 正确做法是用切片模拟栈：
stack := []*Node{root}，避免启动任何 goroutine
真正可控的栈管理只有两条路：要么让帧足够小（逃逸分析准、不用大数组、不捕获大闭包），要么把状态挪到堆上（显式栈、对象池、channel 控制并发粒度）。别信“自动缩容”，也别赌“还能再扩一次”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
