Go中channel本身不会泄漏，真正的泄漏是goroutine因channel操作永久阻塞而无法退出，导致栈内存及所引用资源持续占用；需通过超时、context取消、可控关闭和堆栈检测来避免。
channel 本身不会泄漏，但持有它的 goroutine 可能永远阻塞
Go 的 channel 是由运行时管理的堆上对象，当没有引用指向它、且所有发送/接收操作都结束后，会被 GC 回收。真正的泄漏不是 channel 内存不释放，而是 goroutine 因为在 channel 上永久阻塞（如无缓冲 channel 发送无人接收、或从已关闭 channel 无限接收）而无法退出，导致其栈内存、局部变量、以及它所引用的资源（如文件句柄、数据库连接、定时器）持续占用。
常见导致 goroutine 泄漏的 channel 使用模式
以下情况极易引发泄漏，且难以通过 pprof 或 runtime.NumGoroutine() 直接定位根源：
- 向无缓冲
channel发送数据，但没有对应的接收者启动，或接收者因逻辑错误未执行 —— 发送方 goroutine 永久挂起 - 从一个永远不会被关闭的
channel循环接收（for range ch），且该channel没有其他 goroutine 负责关闭 - 使用
select等待多个channel，但遗漏default或超时分支，导致在某些路径下永久等待 - 把
channel作为函数参数传入长期运行的 goroutine，但调用方忘记关闭或不再消费，而 goroutine 内部又没做超时/取消处理
如何检测和避免 channel 相关的 goroutine 泄漏
关键不是“防止 channel 泄漏”，而是“确保每个 goroutine 都有明确的退出路径”。实操建议如下：
- 始终为阻塞操作设置超时：用
time.After或context.WithTimeout包裹select，避免无限等待 - 用
context.Context传递取消信号，接收方监听ctx.Done()并主动退出，而不是依赖 channel 关闭 - 避免裸用
for range ch；若必须，确保有且仅有一个 goroutine 负责关闭该channel，且关闭时机可控 - 测试时用
runtime.NumGoroutine()在关键路径前后打点，配合pprof.Goroutine查看堆栈，确认 goroutine 是否如期退出
func worker(ctx context.Context, ch <-chan int) {
for {
select {
case val, ok := <-ch:
if !ok {
return
}
process(val)
case <-ctx.Done():
return // 主动响应取消，不依赖 channel 关闭
}
}
}
泄漏往往藏在“正常逻辑”里，而非明显错误
最危险的情况是：代码在大多数输入下表现良好，只有特定边界条件（如上游服务超时、重试失败、配置缺失）触发某条 goroutine 启动路径，却没配对的退出逻辑。比如一个 HTTP handler 启动了后台 goroutine 处理异步任务，但 handler 返回前没 cancel context，也没等 goroutine 结束 —— 每次请求都会悄悄多留一个 goroutine。这种泄漏要靠压力测试 + pprof goroutine profile + 人工 review 路径才能暴露。
