Go 语言中 context.WithTimeout 的定时器资源回收-Golang-PHP中文网

不调用 cancel() 会导致定时器 goroutine 泄漏；context.WithTimeout 启动的 goroutine 会持续运行至超时，即使业务已结束，且高频使用时引发 goroutine 和 timer 堆积、阻碍 GC。

go 语言中 context.withtimeout 的定时器资源回收

不调用 `cancel()` 会导致定时器 goroutine 泄漏

Go 的 context.WithTimeout 内部会启动一个独立的 goroutine，用来在超时时间到达时关闭 ctx.Done()。这个 goroutine 由 *timerCtx 管理，它持有一个 *time.Timer 实例，并通过 channel 发送信号。

如果忘记调用返回的 cancel() 函数，即使业务逻辑早已结束，该定时器也不会被停止，goroutine 会一直运行到超时触发——哪怕你只用了 10ms 就返回了结果，它仍要等满整个 timeout 时间（比如 5s）才退出。

timerCtx 不会自动感知“子任务已完成”，它只认 cancel() 或超时
高频创建 context（如每 HTTP 请求都 WithTimeout）时，泄漏的 goroutine 和 timer 会快速堆积
泄漏的 timer 还会阻止关联的 *time.Timer 被 GC，因为其内部有未释放的系统资源引用

`defer cancel()` 必须在 goroutine 启动之后、退出之前调用

常见错误是把 defer cancel() 放在 goroutine 启动前，比如：

cancel()

若子 goroutine 是“一次性任务”，应在内部监听 ctx.Done() 并自然退出，外层在 wait 后再调用 cancel()
若子 goroutine 是长期 worker（如轮询），必须在 select 中显式处理 ，并在退出前释放资源
绝不要在 goroutine 外部用 defer cancel() 试图“保底”——它和 goroutine 生命周期不匹配

HTTP handler 中基于 `r.Context()` 派生 timeout context 才能避免双重泄漏

直接用 context.Background() 调 WithTimeout 是危险的：它切断了与客户端连接状态的联动。用户关闭页面后，你的 timeout context 仍会继续倒计时，同时父 context（r.Context()）也因子 context 未 cancel 而无法被回收。

标准库的 http.Request.Context() 本身就是一个可取消 context——当客户端断连，它会自动触发取消。你应该在此基础上叠加超时：

使用Go语言搭建家庭相册系统-相关课件

下载

func handler(w http.ResponseWriter, r *http.Request) {
    // ✅ 正确：继承请求生命周期，再加业务超时
    ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)
    defer cancel() // 这里 defer 是安全的：handler 函数退出 = 请求生命周期结束
<pre class="brush:php;toolbar:false;">req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
// ...

}