如何避免Go goroutine泄漏_Go并发资源管理技巧_技术教程

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")
}