goroutine泄漏比开销更危险，真正危害在于未回收的goroutine，如channel未关闭、select阻塞、HTTP handler中goroutine生命周期失控；应通过pprof、NumGoroutine打点排查，优先复用对象、使用errgroup和context控制并发。
goroutine 泄漏比开销更危险，先确认是否真在泄漏
很多人一提“goroutine 开销”就急着调优，其实绝大多数场景下，goroutine 本身内存开销（初始栈 2KB，按需增长）和调度成本极低；真正拖垮服务的是**未回收的 goroutine**——比如忘记 close channel、select 没写 default 或 case 永远阻塞、HTTP handler 中启了 goroutine 却没控制生命周期。
排查方法：
- 用
pprof查看/debug/pprof/goroutine?debug=2，重点关注状态为chan receive或select的长期存活 goroutine - 在关键入口加
runtime.NumGoroutine()打点，观察是否随请求量线性增长 - HTTP 服务中，避免在 handler 内直接
go f()，改用带 context 取消的模式
用 sync.Pool 复用 goroutine 本地对象，而非反复 new
高频创建小对象（如 bytes.Buffer、自定义请求上下文结构体）会加剧 GC 压力，间接抬高 goroutine 调度延迟。这时复用比减少 goroutine 数量更有效。
示例：避免每次 HTTP 请求都 new 一个 bytes.Buffer
var bufferPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
func handle(w http.ResponseWriter, r *http.Request) {
buf := bufferPool.Get().(*bytes.Buffer)
buf.Reset() // 必须重置！
defer bufferPool.Put(buf)
// ... use buf
}
注意：sync.Pool 不保证对象一定被复用，也不保证线程安全地“持有”，所以每次取出来必须初始化/重置；不适合存放含外部引用或需严格生命周期管理的对象。
用 errgroup.Group 替代裸 go + wait.WaitGroup
裸写 go f() 配合 sync.WaitGroup 容易出错：Add 漏调、Done 多调、panic 后没 recover 导致 Wait 永远卡住。而 errgroup.Group 自动处理取消传播、错误聚合与等待逻辑。
