Go goroutine栈初始2KB，通过编译器在函数入口插入栈检查指令，比对SP与stackguard0（约8KB安全水位线），若预估帧大小超剩余空间即触发runtime.morestack扩容。
Go 的 goroutine 栈不是固定 2KB，也不是“用多少给多少”的无感模型——它是一套带预判、拷贝、不缩容的显式内存管理机制，写错一行局部变量就可能触发 runtime.morestack。
为什么 var buf [4096]byte 在函数里一声明就扩容？
编译器在函数入口插入栈检查指令，比对当前 sp 和 stackguard0（距栈顶约 8KB 的安全水位线）。只要这次调用所需帧大小 + 当前剩余空间 runtime.morestack。
- 一个
[4096]byte占 4KB，加上函数调用开销（返回地址、寄存器保存等），很容易跌破stackguard0 - 哪怕只多用 1 字节，只要被判定“可能溢出”，就整栈复制：申请新栈（2KB → 4KB）、memcpy 全量内容、重写所有栈上指针（包括
g.stack.lo/g.stack.hi） - 递归函数中每层都声明大数组，等于每层都触发一次扩容，
pprof里runtime.growstack会高频出现
runtime.newproc: function arguments too large for new goroutine 怎么破？
goroutine 启动时，所有参数必须一次性复制进新栈。初始栈仅约 2KB（Linux/macOS），而参数总大小超过可用空间（源码硬限 ≈ _StackMin - 4096）就会 panic。
- 错误不是发生在函数执行中，而是在
go f(x, y, z)调度前就失败 - 传指针能解决，但注意：结构体里含大数组（如
[1024]int）、未压缩的[]byte或长字符串，仍算“值类型参数” - 更稳妥的做法是：把大参数封装进结构体，再传
*T；或用sync.Pool复用对象，避免每次新建
怎么确认代码正在频繁扩容？别等 CPU 炸了才看
靠 pprof 里 runtime.morestack 占高已经晚了——那是扩容已成性能瓶颈的结果。得在运行时捕获增长信号。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 启动加
GODEBUG=gctrace=1，日志里会出现stack growth: g[123] grew stack from 2048 to 4096 bytes - 用
go tool trace过滤runtime.morestack事件，看频次和调用栈上下文，定位具体函数 - 实操验证：写个递归函数，用
runtime.ReadMemStats对比前后StackSys字段，增量就是实际扩容消耗
栈真的会缩容吗？别信文档里的模糊说法
Go **没有运行时主动缩容机制**。函数返回、局部变量失效、栈顶回退，底层分配的栈内存块仍保留不动。
- 所谓“栈缩小”，只发生在 goroutine 彻底退出时：栈内存归还给
stackpool或stackLarge缓存，供后续复用，但不会返还 OS -
runtime/debug.Stack()显示栈地址范围变小 ≠ 缩容，只是快照，不反映内存是否释放 - WASM 目标下
_StackMin可能为 1KB，测试环境若用 Linux 二进制压测，会漏掉真实栈压力
最易被忽略的点：defer 函数体内再声明大变量，可能引发“扩容嵌套”——第一次扩容刚搬完栈，defer 执行又触发第二次，延迟毛刺明显。这类问题在线上表现为偶发性卡顿，而非 panic，排查时容易绕弯。
