Go协程栈增长是函数调用前预判式搬栈，非实时扩容；仅在入口检查SP与stackguard0，触发则整体复制到更大连续内存，且栈不主动收缩，仅goroutine退出时归还至stackpool或stackLarge。
goroutine 栈增长不是“实时扩容”，而是函数调用前的预判式搬栈
Go 不会在你 push 一个 byte 时检查栈剩余空间，而是在每个函数入口由编译器插入栈边界检查指令——比对当前栈指针 SP 和 stackguard0（距栈顶约 8KB 的安全线）。一旦 SP ，立刻跳转到 <code>runtime.morestack，触发整栈复制。
这意味着：哪怕函数只多声明了 1 字节局部变量，只要编译期预估帧大小超出当前可用空间，就强制分配新栈（2KB → 4KB → 8KB → … → 64KB 后按 +64KB 增），并调用 copystack 全量复制旧数据、重写所有指针（含寄存器和 g.stack.lo/g.stack.hi）。
- 典型误触场景：
var buf [4096]byte{}（编译期算出需 ~4KB，初始 2KB 不够）、defer中闭包捕获大结构体（实际压栈的是整个值，不是指针） - 递归不等于每层都扩容：只有某次调用预估帧 > 当前剩余空间时才触发，不是“第 N 层必然崩”
- WASM 目标下
_StackMin可能为 1KB，跨平台测试必须用真实GOOS/GOARCH
goroutine 栈根本不会运行时收缩，所谓“缩容”只发生在 goroutine 退出时
函数返回后，栈指针 SP 回退，但 g.stack.lo 和 g.stack.hi 这两个边界值只增不减。你用 runtime.Stack() 看到地址范围变小，只是快照反映当前活跃栈帧长度，并非内存已回收。
真正释放栈内存的唯一时机是 goroutine 彻底退出：此时内存归还给 runtime 内部的 stackpool（≤32KB 小栈）或 stackLarge（>32KB 大栈），供后续 goroutine 复用，但不会返还操作系统——除非 GC 决定回收整个 span。
立即学习“go语言免费学习笔记（深入）”；
-
debug.SetMaxStack已被移除，任何调用都会编译失败 - 用
unsafe手动改g.stack会导致 GC 扫描错乱、指针重写失败，触发fatal error: stack overflow -
defer里清空大变量（如buf = nil）不影响已分配的栈空间，局部变量声明本身已计入帧大小
并发成本不能只看 2KB 初始栈，得算清增长开销和内存滞留代价
创建 goroutine 的开销确实很低（微秒级调度 + 2KB 栈），但高频触发栈增长会明显拖慢性能：一次 copystack 包含内存复制 + 指针重写，若每毫秒都扩，runtime.morestack 在 pprof 里会吃掉大量 CPU 时间。
更隐蔽的代价是内存滞留：短生命周期 goroutine 频繁创建/退出，会导致 stackpool 积压，RSS 内存居高不下，但 pprof heap 完全不显示——因为这些内存不在堆上，属于 runtime 管理的栈池。
- 避免在 hot path 函数中声明 >1KB 的局部数组，改用
make([]byte, N)分配到堆上 - 深度递归务必设硬上限，或改用 slice 模拟栈 + 循环，绕过编译器帧大小预估
- 观察
GODEBUG=gctrace=1日志中的stack growth行，若stackalloc远多于stackfree，说明栈在堆积
别迷信“动态伸缩池”，goroutine 本身已是轻量级，真正要控的是并发上限
所谓“动态 goroutine 池”常被误解为预分配 worker 并管理其生命周期，但 Go 的 goroutine 创建成本极低，瓶颈通常在共享资源争用或 I/O，而非启动延迟。与其维护复杂状态机，不如用 channel 实现二进制信号量（bounded semaphore）控制最大并发数。
这种模式天然支持：上限可控（channel 缓冲区容量）、零成本等待（sem ）、自动释放（<code>）、无状态——任务驱动，无任务则无 goroutine，完全避免 idle 协程驻留。
- 负载上升时：任务涌入 →
sem.Acquire()排队 → 最多maxConcurrency个 goroutine 并发执行 - 负载下降时：无新任务 → 不再创建 goroutine → 已完成的自然退出 → 零残留
- 极端空闲时：0 任务 → 0 goroutine 运行 → 完全无资源占用
真正的复杂点不在“怎么伸缩”，而在识别哪些操作会隐式抬高栈需求——比如 defer 捕获大对象、交叉编译目标栈初始值差异、或把本该堆分配的大缓冲写成局部数组。这些细节不暴露在代码表面，却直接决定 runtime 是否频繁搬家。
