Go 连续栈扩容时，goroutine 的栈指针会自动更新吗？

不会自动更新——但 Go 运行时在每次函数调用前会检查栈空间，若不足则触发栈复制（stack copy），并把当前栈上所有活跃变量（包括局部指针）的地址重映射到新栈。这个过程对用户透明，但前提是这些指针必须是「栈上可追踪的」。

• 如果指针是 *int 类型且指向栈上变量（比如 &x），运行时能识别并修正；
• 如果指针是通过 unsafe.Pointer + 偏移硬算出来的（比如 unsafe.Add(unsafe.Pointer(&x), 8)），运行时无法识别，扩容后该地址失效；
• 如果指针被存入全局 map 或 channel 等堆结构中，而原栈变量已随 goroutine 调度被复制，旧地址将悬空——这属于典型的「栈逃逸未发生却误用栈地址」问题。

runtime.stackGrow 不是你该直接调用的函数

Go 没有暴露栈扩容的控制接口。runtime.stackGrow 是内部函数，仅在 runtime 启动和少数特殊路径中由汇编触发，用户代码无法调用，也不应尝试绕过 GC 栈扫描逻辑去手动干预。

• 栈大小由编译器静态分析+逃逸分析决定：小对象优先留在栈，大对象或可能逃逸的会被分配到堆；
• 你看到的“栈扩容”其实是 runtime 在函数入口做的隐式检查：morestack → newstack → 复制旧栈 → 跳回原函数；
• 频繁扩容（比如递归过深、局部数组过大）会导致性能抖动，此时应检查是否真需要那么大的栈帧，或改用切片+堆分配。

为什么 defer 和闭包捕获的变量在扩容后仍可用？

因为它们不是靠原始栈地址维持的——Go 编译器会把闭包捕获的变量提升为堆分配（除非确定生命周期短且不逃逸），而 defer 记录的是函数指针+参数值（或其副本），参数若为指针则指向的仍是有效内存（栈复制后已重映射）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 注意：如果 defer 参数是 &x，且 x 是栈变量，那它在扩容后依然有效，因为运行时重写了整个栈帧；
• 但如果 defer 中用了 unsafe 操作（比如把 &x 转成 uintptr 再传入），就失去追踪能力，扩容后该 uintptr 指向旧栈地址，读写会 panic 或静默损坏；
• 典型错误示例：go func() { println(uintptr(unsafe.Pointer(&x))) }() —— 这个 uintptr 不会被栈复制逻辑识别。

连续栈（Contiguous Stack）和老式分段栈的区别在哪？

Go 1.3 之后弃用了分段栈（segmented stack），改用连续栈：每次扩容不是拼接新段，而是分配一块更大的连续内存，把旧栈内容完整复制过去，再释放旧栈。这是为了消除“栈跨越段边界时的额外检查开销”。

• 连续栈让函数调用更可预测，但也意味着一次扩容成本更高（O(n) 复制）；
• 栈初始大小是 2KB（amd64），上限默认无硬限制，但受限于 OS 进程栈总限制（如 Linux 默认 8MB per process）；
• 如果你在 CGO 调用中传入了 Go 栈上的地址（比如 C 函数里存了 &x），连续栈扩容后该地址失效——CGO 是唯一真正暴露栈地址不稳定的场景。

事情说清了就结束。真正要小心的不是扩容本身，而是任何把栈地址转成不可追踪形式的操作，尤其是混用 unsafe 和跨 goroutine / 跨语言边界的指针传递。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！