Go 1.3 起默认采用连续栈：初始栈2KB，扩容时复制旧栈并修正指针，消除分段栈的检查开销与GC扫描难题，但带来复制停顿；栈大小动态调整，上限1GB，超限仍panic；defer/recover在扩容中可靠，因运行时重定位_defer结构；监控StackSys可定位栈内存异常。
Go 1.3 之前用分段栈，现在默认是连续栈
Go 运行时早期（1.3 之前）用的是分段栈（segmented stack）：每个 goroutine 初始栈很小（4KB），快用完时动态分配新段、拼接指针链。这带来两个硬伤：stack split 时需检查每个函数调用点是否可能溢出，编译器得插大量检查指令；更麻烦的是，Cgo 调用或栈上持有指针的场景下，垃圾回收器难以安全扫描不连续的栈段。
Go 1.3 彻底切换为连续栈（contiguous stack）：初始栈仍是 2KB（Linux/AMD64），但扩容时直接 mmap 一块更大的内存，把旧栈内容完整复制过去，再更新所有栈上指针（包括寄存器和 goroutine 结构体里的 stack.hi/stack.lo）。这意味着：
- 不再需要每层函数都插
morestack检查，性能更稳 - GC 可以像扫普通内存一样线性遍历栈，指针追踪更可靠
- 代价是扩容瞬间有停顿（复制 + 修正指针），且必须预留“复制窗口”——旧栈不能立刻
munmap，得等所有引用被更新完毕
goroutine 栈大小不是固定值，但扩容有明确触发条件
Go 不允许手动指定 goroutine 栈大小，运行时全权管理。初始栈大小由架构决定（runtime.stackMin，通常是 2KB 或 4KB），扩容触发点很直接：当前栈剩余空间不足时，进入函数前的 lessstack → newstack 流程会被激活。关键点在于：
- 不是“用满才扩”，而是“预判不够用”——编译器在函数入口插入检查，依据是该函数帧所需栈空间（含局部变量+调用开销）
- 扩容后新栈大小是旧栈的 2 倍（上限为 1GB），但不会无限倍增：到 64KB 后每次只增 64KB，避免小 goroutine 突然吃掉百 MB 内存
- 递归过深仍会
panic: runtime: goroutine stack exceeds 1000000000-byte limit，这不是 bug，是硬保护
为什么 defer 和 recover 在栈扩容时依然可靠
很多人担心栈复制会破坏 defer 链或 recover 的上下文。其实 Go 在 newstack 过程中会显式重定位所有活跃的 _defer 结构体，包括它们指向的函数指针和参数地址。真正要注意的是：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
defer函数体内如果分配了大量栈空间（比如大数组），可能再次触发扩容，形成嵌套复制——虽罕见，但会导致延迟毛刺 -
recover只捕获当前 goroutine 的 panic，和栈物理位置无关；但若 panic 发生在栈复制中途（极小概率），运行时会先完成复制再抛出，行为一致 - 不要在
defer里做阻塞操作（如 channel send/receive），因为栈扩容本身不暂停调度器，但阻塞会拖慢整个 P 的执行
调试栈行为：看 runtime.ReadMemStats 和 GODEBUG=gctrace=1
想确认某次请求是否因栈频繁扩容影响性能？别猜，用数据说话。最轻量的方式是开启 GC 跟踪并观察 scvg 行里的 STK 字段（表示栈内存总量），或者直接调用：
var m runtime.MemStats
runtime.ReadMemStats(&m)
fmt.Println("StackSys:", m.StackSys)
StackSys 是当前所有 goroutine 栈占用的系统内存总和（含已分配未使用的部分）。如果它随并发数线性增长且远超预期（比如平均 goroutine 栈长期 >1MB），就要检查是否有：
- 无意的大栈分配（如
buf := make([]byte, 1024*1024)在函数内） - 深度递归没设边界（尤其 JSON/XML 解析、AST 遍历）
- CGO 调用后栈未及时收缩（Go 1.14+ 改进过，但老版本仍可能滞留）
连续栈让 goroutine 更健壮，但也把“栈失控”的问题从“崩溃”转向“静默吃内存”。盯住 StackSys，比读源码更能快速定位真实瓶颈。
