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
立即学习“go语言免费学习笔记（深入）”；
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 自动处理取消传播、错误聚合与等待逻辑。
典型误用：
var wg sync.WaitGroup for _, url := range urls { wg.Add(1) go func() { defer wg.Done() fetch(url) // 可能 panic }() } wg.Wait() // 若 fetch panic，这里永远等不到 Done改用 errgroup：
g, ctx := errgroup.WithContext(r.Context()) for _, url := range urls { url := url // 避免闭包引用 g.Go(func() error { return fetchWithContext(ctx, url) }) } if err := g.Wait(); err != nil { // 错误统一处理 }它还自动继承 context 取消信号，上游 cancel 后所有子 goroutine 可及时退出，避免资源滞留。
长连接场景下慎用无限 for-select，优先考虑 channel 缓冲 + 超时控制
websocket、MQTT client 等长连接常写成 for { select { case ，看似简洁，但若 ch 长期无数据，goroutine 就空转占着调度器 slot；更糟的是，一旦 channel 关闭而没检查 ok，会进入死循环。
改进方式：
- 给接收 channel 加缓冲（如
make(chan T, 64)），降低唤醒频率 - 在
select中加入case 做保底心跳或清理 - 总是检查
val, ok := ，!ok时主动退出 goroutine - 对非关键后台任务，用
runtime.Gosched()主动让出时间片（仅限极少数轮询场景）
goroutine 的“开销”问题，本质是生命周期失控和资源复用不足；与其纠结数量，不如盯紧 go 出现的位置、channel 是否可关闭、context 是否可取消、对象是否在反复分配。这些地方松动一寸，压测时可能崩掉一整台机器。