单个 Goroutine 初始栈约2KB，但泄漏时十万例可占200MB+内存并引发GC与调度恶化；需用runtime.MemStats.StackInuse和pprof/goroutine?debug=2定位卡死协程，避免“一请求一goroutine”导致栈膨胀、僵尸协程及GC压力。
单个 Goroutine 初始只占约 2KB 栈空间，但失控增长或泄漏时，十万个就能吃掉 200MB+ 内存，且伴随 GC 压力飙升和调度器卡顿——这不是理论极限，而是线上服务挂掉前的真实征兆。
如何用 runtime.MemStats 和 pprof 定位 Goroutine 内存真实开销
别只看 runtime.NumGoroutine() 数值，它不反映内存占用。真正关键的是 Goroutine 背后堆分配和栈膨胀情况：
- 用
runtime.ReadMemStats(&stat)检查stat.HeapAlloc和stat.StackInuse，后者直接体现所有 Goroutine 当前栈总用量（注意：不是初始 2KB × 数量，而是实际已分配的栈内存） - 访问
/debug/pprof/goroutine?debug=2时重点过滤状态为chan receive、semacquire、netpoll的 Goroutine——它们若停留超 10 秒，大概率已卡死并持续持有栈+堆内存 -
pprof.Lookup("goroutine").WriteTo(w, 1)输出的 goroutine 堆栈里，若大量出现runtime.gopark，说明 P 正在频繁挂起/唤醒，而非执行业务，此时 CPU 可能不高，但内存和延迟已恶化
为什么“一请求一 goroutine”在高并发下必然引发内存压力
HTTP handler 中写 go handle(r) 看似轻量，实则埋下三重内存隐患：
- 每个新 Goroutine 至少分配 2KB 栈，10K 并发即 20MB；若其中部分调用链深（如递归、多层中间件），栈会动态扩容，单个涨到 512KB 很常见
- 未绑定
context.Context的 Goroutine 无法被主动取消，一旦下游超时或连接断开，它仍卡在 channel 等待或 HTTP write 上，变成“僵尸 Goroutine”持续占内存 - 大量短命 Goroutine 频繁创建/销毁，导致 GC 扫描对象数激增，STW 时间变长，进一步拖慢响应，形成恶性循环
worker pool + buffered channel 的缓冲区怎么设才不踩坑
缓冲区大小不是性能参数，而是内存水位控制阀。设错会导致积压或阻塞，两者都推高内存：
- 缓冲区过小（如
make(chan *Task, 10)）：提交方频繁阻塞在ch ，可能触发超时重试或堆积本地切片，内存从 Goroutine 转移到主协程 - 缓冲区过大（如
make(chan *Task, 10000)）：任务滞留在 channel 底层环形队列中，GC 无法回收其引用的对象（如*http.Request），造成隐性堆内存泄漏 - 推荐公式：
buffer_size = QPS × avg_task_duration × 1.5，例如 QPS=200、平均处理 100ms → 缓冲设 30；上线后必须监控len(ch)，持续 >80% 容量就要告警
defer 在循环里闭包捕获变量导致的 Goroutine 内存泄漏
这个坑极隐蔽：表面没启新 Goroutine，但 defer 本身就在当前 Goroutine 分配结构体，循环中滥用等于批量制造内存钉子：
- 错误写法：
for _, v := range items { defer close(v.ch) }→ 每次迭代都 new 一个_defer结构体（约 32 字节），且 v.ch 引用被逃逸到堆，整个items切片无法被 GC - 正确做法：把 defer 提到循环外，或改用显式关闭；若必须延迟执行，用函数切片缓存：
var cleanups []func(); for _, v := range items { cleanups = append(cleanups, func() { close(v.ch) }) }，再统一执行 - 验证方式：加
go tool compile -gcflags="-m"编译，若输出含... moved to heap且关联 defer，基本可确认逃逸路径
真正难控的从来不是 Goroutine 数量，而是它的生命周期是否与业务语义对齐——一个没被 context 控制、没被 WaitGroup 等待、也没被 channel 流量削峰的 Goroutine，无论多轻，都会在某个凌晨三点悄悄把内存耗尽。
