协程泄漏主因是卡在阻塞操作而非未退出，如向无缓冲无人接收的channel写入、等待永不关闭的channel等；常用done channel主动通知退出。
理解协程泄漏的根本原因
协程泄漏通常不是因为 goroutine 没有退出，而是它卡在某个阻塞操作上长期无法结束，比如：
– 从已关闭但未被消费完的 channel 读取（会一直返回零值，不阻塞，但逻辑可能陷入死循环）
– 向无缓冲且无人接收的 channel 写入（永久阻塞）
– 等待一个永远不会关闭的 channel 或超时未设的 timer
– 在 select 中缺少 default 分支，又没有其他 case 就绪，导致挂起
用 done channel 主动通知协程退出
最常用也最可控的方式是通过额外的 done channel 传递退出信号。主协程关闭它，工作协程监听并优雅退出：
// 启动工作协程
go func(done
for {
select {
case data := // 处理数据
case // 收到退出信号，清理后返回
return
}
}
}(done)
注意：
– done 一般用 chan struct{}，零内存开销
– 关闭 done 即可广播信号，无需发送值
– 所有监听 done 的协程都会同时收到通知
立即学习“go语言免费学习笔记（深入）”；
关闭 channel 的正确时机与禁忌
channel 只应由“写入方”关闭，且**只能关闭一次**。常见错误包括：
– 多个协程竞态关闭同一 channel（panic: close of closed channel）
– 读取方误关 channel（违反职责分离，易引发 panic 或逻辑混乱）
– 在仍有协程试图写入时就关闭（导致 panic: send on closed channel）
安全做法：
– 使用 sync.WaitGroup + 单一写入协程管理关闭
– 或用 context.WithCancel 配合 done channel，避免直接关 channel
– 若必须关 channel，确保所有写入已完成，并用 defer 或显式逻辑保证只关一次
结合 context 管理超时与取消更可靠
对于有 IO、网络、定时等不确定耗时的操作，优先使用 context 而非裸 channel 控制生命周期：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // 防止上下文泄漏
go func(ctx context.Context) {
for {
select {
case // 定期任务
case // ctx 被取消或超时，退出
return
}
}
}(ctx)
context 能自动传播取消信号、支持超时/截止时间、可嵌套、与标准库深度集成，比手动维护 done channel 更健壮。
