Goroutine 泄漏必然发生而非偶发，因未显式控制退出会导致内存持续增长、调度变慢；须用 context 管理生命周期，避免无出口 for 循环或未监听的 select。
Go 中的 goroutine 泄漏不是“偶尔发生”，而是只要没显式控制退出，就一定会发生——它不报错、不 panic，只悄悄吃内存、拖慢调度，直到某天线上告警突增。
用 context 控制生命周期，别信“它自己会结束”
很多人写 go func() { for { ... } }() 就完事，以为业务逻辑跑完 goroutine 就自动回收。错：只要 for 没出口、select 没监听 ，它就永远卡在运行队列里。
- 必须用
context.WithCancel或WithTimeout创建可取消上下文，并在启动 goroutine 时传入 - 在
select中始终把作为第一分支，且不能放在default后面 - 调用
cancel()的位置要明确：比如 HTTP handler 返回前、任务完成回调里、或defer中（如果生命周期确定）
func worker(ctx context.Context) {
for {
select {
case <-ctx.Done():
return // 必须有这一行
default:
doWork()
time.Sleep(100 * time.Millisecond)
}
}
}
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel() // 这里 defer 是安全的，因为 ctx 生命周期明确
go worker(ctx)
channel 操作不配 close 或 select 超时，等于主动制造阻塞点
无缓冲 channel 的发送/接收是同步的；一旦一方消失，另一方就永久挂起。pprof 里看到大量 chan send 或 chan receive 状态的 goroutine，90% 是这个原因。
- 不要对无缓冲 channel 做单向写入，除非你 100% 确保有且仅有一个接收者在运行
- 接收方必须检查
ok（v, ok := ），否则从已关闭 channel 读取会持续返回零值，可能引发逻辑错误 - 优先用带超时的
select，而不是裸写 - 发送方完成任务后，应主动
close(ch)，而非靠 GC “等它死”
ch := make(chan int, 1) // 改用带缓冲，避免一写就阻塞
go func() {
select {
case ch <- 42:
case <-time.After(1 * time.Second):
// 超时处理，不卡住
}
}()
// 接收端
select {
case v := <-ch:
fmt.Println(v)
case <-time.After(1 * time.Second):
fmt.Println("timeout")
}
测试阶段用 goleak 卡死泄漏，别等上线才看 runtime.NumGoroutine()
runtime.NumGoroutine() 只能告诉你“数量涨了”，但不知道哪来的、为什么没退。而 goleak 能直接定位到泄漏 goroutine 的启动栈，是测试期最有效的守门员。
- 单元测试加
defer goleak.VerifyNone(t)，失败时立刻打印泄漏 goroutine 的完整调用链 - 整个包测试用
TestMain+goleak.VerifyTestMain(m)，避免跨测试函数的残留干扰 - 注意：不能和
t.Parallel()混用，否则会误报——并行测试请统一走VerifyTestMain - 忽略标准库 goroutine 用
goleak.IgnoreTopFunction("runtime.gopark")，但别滥用，先确认是不是真无关
最常被忽略的一点：第三方库（比如 sql.DB、http.Client、日志上报器）内部启动的 goroutine，不会因为你 main 函数结束就自动停。它们往往需要显式调用 Close() 或 Stop()。查文档，别假设。
