goroutine泄漏典型表现为内存持续上涨、CPU不降及pprof显示大量goroutine阻塞在chan receive/select；定位需用runtime.NumGoroutine()打点日志并访问/debug/pprof/goroutine?debug=2查堆栈。
goroutine 泄漏的典型表现和快速定位方法
启动大量 goroutine 后程序内存持续上涨、CPU 占用不降，或 pprof 显示大量 goroutine 处于 chan receive 或 select 等待状态，基本可以判定存在泄漏。根本原因常是 channel 未关闭 + 接收端未退出，或 WaitGroup 的 Add/Done 不配对。
- 用
runtime.NumGoroutine()在关键点打日志，观察数量是否回落 - HTTP 服务下访问
/debug/pprof/goroutine?debug=2查看完整堆栈 - 所有带循环的 goroutine 必须有明确退出条件，避免无休止
for {}
channel 关闭时机必须由发送方决定
channel 是并发安全的，但关闭行为本身不是原子操作；多个 goroutine 同时 close(ch) 会 panic：panic: close of closed channel。因此，**只有唯一发送方（或经协调的发送方）才能调用 close()**，接收方只负责读取直到 ok == false。
- 若使用
for range ch，channel 关闭后自动退出循环 —— 这是安全的惯用法 - 若用
select配合case v, ok := ，需显式检查ok并 break - 绝不要在多个 goroutine 中都写
if ch != nil { close(ch) }
go func() {
defer wg.Done()
for i := 0; i < 5; i++ {
ch <- i
}
close(ch) // ✅ 唯一关闭点
}()WaitGroup 与 channel 组合使用的正确模式
常见错误是把 wg.Add(1) 放在 goroutine 内部，导致主 goroutine 提前等待；或忘记 wg.Done()，造成死锁。标准协作结构是：启动前 Add，退出前 Done，channel 负责数据传递，WaitGroup 负责生命周期同步。
-
wg.Add(n)必须在 goroutine 启动前执行，且不能被并发调用 - 每个 goroutine 结束前必须调用
wg.Done()，推荐用defer wg.Done() - 若 goroutine 可能因 channel 关闭提前退出，
defer仍能保证Done执行
ch := make(chan int, 3) var wg sync.WaitGroup// 启动 3 个 worker for i := 0; i < 3; i++ { wg.Add(1) go func(id int) { defer wg.Done() for v := range ch { fmt.Printf("worker %d got %d\n", id, v) } }(i) }
// 发送数据 for i := 0; i < 5; i++ { ch <- i } close(ch)
wg.Wait() // 等待所有 worker 退出
立即学习“go语言免费学习笔记（深入）”；
何时该用 channel，何时该用 WaitGroup
channel 不是万能同步原语。它适合传递数据、控制流（如退出信号）、或实现生产者-消费者模型；WaitGroup 只解决“等一组 goroutine 结束”这一个事。混用时容易过度设计 —— 比如仅为了等结束而创建无缓冲 channel 做通知，不如直接用 WaitGroup 简洁。
- 需要传值、背压、或解耦生产/消费节奏 → 用 channel
- 只关心“它们干完了没”，且无数据交互 → 用 WaitGroup
- 既要等结束，又要收集返回结果 → channel 更自然（如
chan result） - 超时控制、取消传播 → 应优先考虑
context.Context，而非靠 channel + timer 拼接
真正难的不是语法，是判断哪个 goroutine 该关 channel、哪个该关自己、哪个该被 WaitGroup 等 —— 这取决于你定义的职责边界。一旦发送方结束，就该关 channel；一旦 worker 完成全部任务（包括处理完 channel 关闭），就该 Done；没有明确的“最后一个”概念，只有清晰的状态契约。
