栈增长在每次函数调用前预判触发，而非爆栈时；编译器在入口插入检查指令，比对SP与stackguard0（距栈顶约8KB），超限即调runtime.morestack扩容。
栈增长什么时候发生？不是爆栈才触发，而是调用前就预判
Go 的栈增长根本不是等你 panic: runtime: goroutine stack exceeds 1000000000-byte limit 才反应——它在每次函数调用前就检查：这个函数要的栈帧，当前还剩多少空间？够不够？
判断依据是 stackguard0，一个离栈顶约 8KB 的“安全缓冲区”。只要栈指针 SP 落到它下面，立刻跳转到 runtime.morestack 开始扩容。编译器自动在函数入口插检查指令，你完全感知不到，但也意味着：哪怕只多用 1 字节，只要被判定“可能溢出”，就整栈搬家。
- 典型触发场景：
func f() { buf := [4096]byte{} }（局部数组超 2KB）、深度递归、defer函数里再声明大变量 - 注意：
defer本身不占多大栈，但它捕获的大闭包变量（比如整个结构体）会一起压栈，容易被忽略 - 增长不是原地扩展，而是分配新栈（2KB → 4KB → 8KB → … → 64KB 后改按 +64KB 增），然后
copystack全量复制 + 重写所有指针（包括寄存器和g.stack.lo/g.stack.hi）
栈真的会缩容吗？别信“自动收缩”的说法
Go 当前**没有运行时主动缩容机制**。函数返回、局部变量失效、栈顶回退，底层分配的内存块仍保留，直到 goroutine 退出才整体释放。
所谓“栈缩小”，只发生在一种情况下：goroutine 彻底结束。此时栈内存归还给 stackpool 或 stackLarge 缓存，供后续 goroutine 复用，但不会返还操作系统（除非 GC 触发并决定回收整个 span）。
立即学习“go语言免费学习笔记（深入）”；
- 常见误解：
runtime/debug.Stack()显示栈地址变小了 = 缩容了？错，这只是快照，不反映内存是否释放 - 参数差异：
_StackMin是 2048（64 位），maxStack是 1 - 兼容性影响：WASM 目标下初始栈更小（
stackMin可能为 1KB），测试环境必须贴近部署平台
怎么确认我的代码正在频繁扩容？别靠猜，看运行时信号
不能只看 pprof 里 runtime.morestack 占 CPU 高——那已经是性能受损的结果。得在问题发生前观察增长行为。
最轻量有效的方式是启动时加调试标志：GODEBUG=gctrace=1，运行中会打印类似：stack growth: g[123] grew stack from 2048 to 4096 bytes；或者用 go tool trace 筛选 runtime.morestack 事件，看频次和调用栈上下文。
- 实操建议：写个递归函数，用
runtime.ReadMemStats对比前后StackSys字段，能清晰看到栈内存增长量 - 性能影响：一次扩容停顿 ≈ 复制耗时 + 指针修正耗时；若每毫秒都扩，
pprof里runtime.morestack会吃掉大量 CPU - 高频扩容的代码特征：hot path 里声明 >1KB 的局部数组、嵌套结构体、或循环内不断逼近栈边界
如何避免栈增长带来的毛刺？关键在控制单次函数栈需求
栈增长本身不可禁用，也不该手动干预（debug.SetMaxStack 已移除，runtime.Stack 返回的是只读快照）。唯一靠谱的路，是让每个函数“胃口”可控。
核心原则：把大内存需求从栈移到堆——让变量逃逸。编译器逃逸分析（go build -gcflags="-m"）是你最该常看的工具。
- 示例：
buf := make([]byte, 4096)逃逸到堆，比buf := [4096]byte{}压栈安全得多 - 交叉编译目标平台影响实际栈大小（如 ARM64 和 wasm 初始栈不同），上线前务必在真实环境压测
- 协程风暴场景（短时大量 goroutine 创建/退出）易导致
runtime.stackalloc内存堆积，不是泄漏，是 GC 没来得及扫；可调低GOGC或用 worker pool 控制并发数
真正复杂的地方在于：栈增长是 Go 运行时全程掌控的原子过程，涉及指针重写、_defer 结构体迁移、GC 扫描连续性保障——你写的每一行 Go 代码，都在这个精巧但不容绕过的机制之上运行。
