go在函数调用前通过stackguard0（约8kb安全缓冲区）预判栈是否够用，sp低于它即触发runtime.morestack扩容；若扩至1gb仍不足，则报栈超限错误。
栈不够用时，Go 怎么知道要扩容？
Go 不是在栈真正“爆掉”那一刻才反应，而是在每次函数调用前就预判：这个函数要的栈空间，当前还剩多少？够不够？判断依据是 stackguard0 —— 它不是栈顶，而是离栈顶预留的一段“安全缓冲区”（通常约 8KB）。只要栈指针 SP 落到 stackguard0 之下，就会立刻跳转到 runtime.morestack 触发扩容。
编译器会在每个可能消耗较多栈空间的函数入口自动插入这段检查逻辑，你完全感知不到。但这也意味着：哪怕一个函数只多用了 1 字节，只要它被判定“可能溢出”，就会触发整栈复制。
- 常见错误现象：
runtime: goroutine stack exceeds 1000000000-byte limit—— 不是没扩容，是扩容到 1GB 还不够，说明递归太深或局部变量过大 - 典型场景：深度递归、大数组声明（如
var buf [64）、嵌套闭包捕获大量数据 - 注意：
defer函数体内若再分配大栈空间，可能引发二次扩容，形成“扩容嵌套”，延迟毛刺明显
扩容时到底发生了什么？
不是“在原地加内存”，而是“搬家”：申请一块新栈（初始 2KB → 扩为 4KB），把旧栈所有内容完整 memcpy 过去，再修正所有栈上指针（包括寄存器里的 SP、BP，以及 g.stack.lo/g.stack.hi），最后释放旧栈。
这个过程是原子的，且 runtime 会显式重定位所有活跃的 _defer 结构体，所以 defer 和 recover 在扩容后依然有效——这点很多人误以为会断链，其实不会。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 扩容策略：2KB → 4KB → 8KB → 16KB → … → 64KB 后改按 +64KB 增长，避免小 goroutine 突然吃掉百 MB 内存
- 性能影响：一次扩容停顿时间 ≈ 复制耗时 + 指针修正耗时；若频繁触发（如每毫秒都扩），
pprof里会看到大量runtime.morestack占用 CPU - 兼容性无问题，但 GC 必须能扫描连续栈——这也是 Go 1.3 放弃分段栈的根本原因
怎么观察和验证栈是否在扩容？
不能靠猜，得看运行时信号。最直接的方式是用 runtime/debug.Stack() 或 pprof 抓取 goroutine 栈快照，观察栈地址范围变化；更轻量的是启用 GODEBUG=gctrace=1 配合 go tool trace，能看到每次 morestack 调用的时间点和调用栈。
- 实操建议：写个递归函数，用
runtime.ReadMemStats对比前后StackSys字段，能清晰看到栈内存增长 - 参数差异：
GOROOT/src/runtime/stack.go里定义了stackMin = 2048（64 位）和maxStack = 1（1GB），不可修改 - 注意：
go tool pprof的top命令里若出现高频runtime.growstack，基本就是栈管理热点
哪些写法会悄悄拖慢栈管理？
不是所有栈使用方式都平等。有些看似无害的写法，会让 runtime 反复搬栈，代价远超预期。
- 在循环内反复声明大数组，比如
for i := range data { buf := [8192]byte{}; ... }—— 每次迭代都压栈 8KB，极易触发扩容 - 用
defer包裹需大量栈空间的操作，如defer func() { _ = heavyCalc() }()，扩容可能发生在 defer 链执行阶段 - 跨 CGO 边界传递大结构体（尤其是含指针的），虽不直接导致扩容，但会让 GC 扫描更重，间接拖慢栈回收节奏
- 避免手动“预估”栈大小——Go 不允许指定 goroutine 栈容量，
runtime.GOMAXPROCS或GOGC也完全不影响单个栈行为
栈扩容本身很健壮，但它的“安静”容易让人忽略背后开销。真正难的不是理解机制，而是在 profile 里识别出那些藏在 morestack 下面的真实瓶颈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
