go goroutine栈初始大小为2kb，但实际起始栈大小动态计算且可复用；自1.3起采用连续栈复制机制，扩容时复制旧栈并修正指针，最大1gb，不缩容，递归或大局部变量易致栈快速膨胀。
goroutine栈初始大小是2KB，但别当真
Go runtime默认给每个新goroutine分配2KB栈空间，这只是起点。它会按需动态伸缩，最大可达1GB。你不需要、也不能手动指定这个值——runtime.Stack不提供设置接口，GOMAXSTACK环境变量也不存在。所谓“合理分配”，本质是让编译器和runtime自己决定何时扩容、何时收缩。
栈分裂（stack split）已被淘汰，现在用栈复制（stack copying）
旧版Go（v1.2前）用分段栈，每次溢出就分配新块并链起来，导致热分裂问题：循环里频繁调用函数 → 频繁扩容+收缩 → 性能雪崩。v1.3起改用连续栈+栈复制机制：
- 栈满时，分配一块**两倍大小**的新内存
- 把旧栈内容完整复制过去
- 更新所有指针指向新地址
- 旧栈内存由GC异步回收（不是立刻归还OS）
这意味着：单次扩容代价变高（要复制），但后续收缩零开销，且避免了链表跳转和热分裂。你写的递归或深层调用不会突然卡住，但要注意——如果某goroutine反复触发扩容（比如超深递归+大局部变量），它的栈可能迅速膨胀到几MB，而这些内存不会马上释放。
什么情况会让栈实际变大？看逃逸分析结果
栈大小不是由变量数量决定的，而是由**单个栈帧所需空间**和**调用深度**共同决定。真正影响栈增长的是：
- 函数参数或局部变量本身很大（如
[1024]int64数组） - 闭包捕获了大对象（
func() { return bigStruct }） - 递归调用层级过深（哪怕每次只压入几个字节，深度10000也会撑满栈）
- 内联被禁用（
//go:noinline）且函数体庞大
验证方法：用go tool compile -gcflags="-m -l" main.go查看是否出现... escapes to heap——如果变量逃逸到堆，它就不占栈；但如果没逃逸却体积巨大，就会直接吃掉栈空间。注意：println比fmt.Println更易触发逃逸，调试时别用错工具。
栈内存残留常被误认为内存泄漏
goroutine退出后，它的栈内存不会立刻归还操作系统，而是等GC扫描时才标记为可回收。如果你短时间启动大量短命goroutine（比如HTTP handler里go handle()），会出现：
- 内存使用曲线呈锯齿状上升，但迟迟不回落
-
pprof显示runtime.stackalloc占用高 -
runtime.ReadMemStats中StackSys持续偏高
这不是bug，是设计使然。缓解方式只有两个：
- 用worker pool控制goroutine并发上限，避免“一请求一goroutine”
- 调低
GOGC（比如设为50），让GC更激进地回收栈内存
别试图用runtime/debug.FreeOSMemory()强制释放——它对栈内存无效，且会干扰GC节奏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
