goroutine本身不触发GC，真正拖垮GC的是其高频创建的临时堆对象；应通过逃逸分析和pprof allocs定位问题，用worker pool限流、sync.Pool复用对象、栈分配优先等手段优化。
goroutine本身不直接触发GC，但附带对象会
频繁调用 go f() 不会让 GC 崩溃，真正拖垮 GC 的是每个 goroutine 里 new 出来的临时对象：比如 *bytes.Buffer、map[string]interface{}、JSON 解析器、HTTP 请求上下文等。这些对象堆分配后，若生命周期短、创建频次高（如每请求一个），就会快速填满 mcache，导致 GC 扫描压力飙升、P99 毛刺明显。
验证方式很简单：go build -gcflags="-m" 看关键变量是否 escapes to heap；再跑 go tool pprof http://localhost:6060/debug/pprof/allocs，重点盯 inuse_objects 涨得最快的函数——大概率就是问题源头。
用 worker pool 替代 for 循环里的 go f()
这是最立竿见影的改动。别让 10 万条数据直接 spawn 10 万个 goroutine；改用固定数量的长期 worker 从 channel 拿任务执行：
- worker 数量建议设为
2 * runtime.NumCPU()，压测过较稳 - 任务 channel 必须带缓冲，大小设为 worker 数的 2–4 倍（例如 8 个 worker →
make(chan func(), 32)），太小阻塞 sender，太大浪费内存 - 每个 worker 必须用
recover包裹执行逻辑，否则 panic 会导致 goroutine 静默退出，池子“漏气” - 别依赖
sync.WaitGroup等所有 goroutine 结束——worker 是长期运行的，用context.WithCancel控制启停更可靠
sync.Pool 只缓存对象，不缓存 goroutine
sync.Pool 对 GC 压力缓解极有效，但必须用对场景和姿势：
立即学习“go语言免费学习笔记（深入）”；
- 只适合「构造开销大 + 生命周期短 + 复用路径明确」的对象，比如
*bytes.Buffer、*json.Decoder、预分配的[]byte -
Pool.Get()返回值可能为nil，必须检查并 fallback 初始化：b := bufPool.Get().(*bytes.Buffer); if b == nil { b = &bytes.Buffer{} } -
Pool.Put()前必须重置状态，比如b.Reset()，否则下次Get()拿到的是脏数据 - 不要缓存含大量指针字段的结构体（如带
map[string]interface{}的 struct），Pool 清空时不触发 finalize，容易滞留内存
能栈分配，就别堆分配
比复用更优的方案是根本不上堆。Go 编译器通过逃逸分析决定分配位置，而栈分配零 GC 开销：
- 避免返回局部变量指针，如
func() *int { i := 42; return &i }→i必然逃逸 - 循环中启动 goroutine 时，用值传递参数而非捕获外部变量：
go func(i int) { ... }(i)比go func() { ... }()更安全，减少闭包逃逸 - 字符串拼接优先用
strings.Builder，它内部复用底层数组且无接口转换开销；读 HTTP body 用io.CopyBuffer(dst, src, make([]byte, 32*1024))显式复用缓冲区 - 切片预分配容量：
make([]byte, 0, 4096)而非make([]byte, 4096)，后者多初始化 4096 字节零值，徒增 GC 扫描量
真正难的不是写对 worker pool 或 sync.Pool，而是判断哪些对象值得放进 Pool、哪些其实该从源头杜绝堆分配。逃逸分析输出和 allocs profile 必须成为日常调试的一部分，而不是等到 P99 毛刺报警才想起看 —— 那时候 GC 已经在喘了。
