协程泄漏本质是程序逻辑缺陷，因缺少退出机制或channel未关闭导致goroutine永久阻塞；应使用context.Context统一控制生命周期，通过ctx.Done()监听取消信号并及时清理。
理解协程泄漏的本质
协程泄漏不是Go语言的bug，而是程序逻辑缺陷：启动了goroutine，但因缺少退出机制或channel未关闭，导致其永远阻塞在select、recv或send上，无法被调度器回收。常见于后台监听、定时任务、管道处理等场景。
用context控制协程生命周期
推荐使用context.Context作为协程的“退出信号源”，而非手动维护布尔标志或额外channel。父goroutine通过context.WithCancel或context.WithTimeout派生子context，子goroutine监听ctx.Done()通道，在收到信号后清理资源并返回。
- 始终在goroutine入口处检查
ctx.Err() != nil，避免启动已取消的协程 - 在
select中把作为必选项，优先响应取消 - 调用
cancel()后，建议用sync.WaitGroup等待协程真正退出，确保资源释放完成
正确关闭channel的三个原则
channel只应由**发送方**关闭，且**只能关闭一次**；接收方关闭会panic；向已关闭channel发送数据也会panic。关闭时机必须明确——通常是所有发送操作结束之后，且不再有新数据要写入。
- 不要在多个goroutine中并发关闭同一channel，可用
sync.Once包装关闭逻辑 - 接收方应通过
val, ok := 判断channel是否关闭（ok==false表示已关） - 若用
for range ch遍历channel，循环会在channel关闭后自动退出，但需确保发送方已关闭，否则会永久阻塞
避免常见陷阱的实践建议
协程泄漏常源于“以为它结束了，其实卡住了”。比如启动一个goroutine读channel，但忘记关闭channel，或发送方提前退出没通知接收方；又如用无缓冲channel做同步，但某一方未执行收/发操作。
- 对长期运行的goroutine，统一加超时兜底：
time.AfterFunc(5 * time.Minute, func(){ log.Println("goroutine stuck?") }) - 用
runtime.NumGoroutine()在测试或调试阶段观察协程数量趋势，发现异常增长 - 在HTTP handler、数据库连接池、消息消费者等关键路径中，显式绑定context并传递到底层，禁止忽略
ctx.Done()
