Go中goroutine内存占用不固定，初始2KB栈可动态增长至几MB，优化关键在控制生命周期与避免逃逸；需警惕闭包捕获、defer积压、channel缓冲过大导致的隐性内存泄漏。
Go 里 goroutine 的内存占用不是固定值，初始 2KB 只是起点；真正吃内存的是栈动态增长、闭包捕获、defer 积压和长期存活——优化重点不在“减少数量”，而在“控制生命周期”和“避免逃逸”。
goroutine 栈大小怎么查和调？
每个 Goroutine 启动时分配 2KB 栈（Go 1.14+ 支持收缩），但递归深、局部变量大、或调用链长时会自动扩容，单个可能涨到几 MB。不加干预的话，runtime.MemStats.HeapAlloc 里看不到栈内存，它算在操作系统虚拟内存里，但会真实挤压堆空间。
- 查当前栈使用：用
runtime/debug.Stack()打印某 goroutine 的栈帧，观察深度和变量尺寸 - 限最大栈：启动前调
debug.SetMaxStack(64 * 1024)（如 64KB），超限直接 panic，防止无限膨胀 - 别信“默认够用”：HTTP handler 里做 JSON 解析 + 模板渲染，很容易突破 8KB；压测时用
pprof.Lookup("goroutine").WriteTo(w, 1)看状态为running且栈帧 >20 层的 goroutine
闭包捕获大对象导致栈无法收缩
常见于循环启 goroutine 时直接引用外部变量，比如 for _, req := range requests { go func() { process(req) }() } —— 这会让整个 *http.Request（含 body、headers、context）被所有 goroutine 共享引用，栈无法收缩，内存常驻。
- 修复方式：显式传参，
go func(r *http.Request) { process(r) }(req) - 更安全的做法：只传需要的字段，比如
go func(id string, path string) { logAccess(id, path) }(req.Header.Get("X-Request-ID"), req.URL.Path) - 检查逃逸：用
go tool compile -gcflags="-m" main.go，看到... moved to heap就说明变量逃逸了，栈变堆，GC 压力翻倍
defer 在循环里堆积引发内存泄漏
defer 不是立即执行，而是在函数 return 前统一调用；如果写在循环里，比如 for _, f := range files { defer f.Close() }，会为每个 f 分配一个 _defer 结构体（约 32 字节），全部挂到当前 goroutine 的 defer 链表上，直到函数结束才释放——十万次循环就是 320KB 白占着。
立即学习“go语言免费学习笔记（深入）”；
- 改法一：把 defer 提到外层函数，或改用显式清理列表：
var cleanups []func(); for _, f := range files { cleanups = append(cleanups, func() { f.Close() }) }; for _, c := range cleanups { c() } - 改法二：用
sync.Pool缓存_defer对象？不行——sync.Pool不管理 defer 链表，这是 runtime 内部结构，无法池化 - 监控手段：
runtime.NumGoroutine()稳定但runtime.ReadMemStats(&m); m.HeapAlloc持续上涨，且 pprof 显示大量 goroutine 卡在runtime.gopark，大概率是 defer 或 channel 积压
channel 缓冲区设多大才不拖慢 GC？
缓冲区本质是 slice，数据存在堆上；过大的 chan int（比如 make(chan int, 10000)）会让 10000 个 int 长期滞留内存，GC 无法回收，直到 channel 被 GC 掉——而 channel 的 GC 时机不可控，尤其当它被闭包捕获时。
- 生产者-消费者场景：缓冲区大小 ≈ 单批处理量 × 1.5，例如日志批量刷盘每批 100 条 → 设
make(chan LogEntry, 150) - 纯信号通道（如
done chan struct{}）必须无缓冲：make(chan struct{})，否则select { case done 可能静默失败 - 监控积压：用
len(ch)定期采样，配合告警；若持续 >80% 缓冲容量，说明消费者跟不上，该加 worker 数，而不是扩缓冲
真正难调的不是单个 goroutine 多占了几 KB，而是成千上万个 goroutine 同时持有指针、缓存未清、channel 未关、defer 未执行——这些“半死不活”的状态才是内存悄悄上涨的元凶。
