Go context 最容易被误用的地方：以为 cancel 会替你收拾现场

Wed, 20 May 2026 17:50:00 +0800

线上接口开始超时，goroutine 数一路往上涨。

你第一反应可能是：不是已经传了 context.WithTimeout 吗？超时到了，goroutine 不就该停了吗？

这就是 Go context 最容易被误用的地方。

context 不负责替你停掉 goroutine。它只负责把“该停了”这句话传到门口。门里的人听不听、什么时候退场，要看你自己的代码。

这篇是 Go context 系列的第一篇。先不急着讲 HTTP、gRPC、database/sql 这些框架怎么接入，也不急着把所有 API 列一遍。

我们先把最底下这层讲清楚：context 到底是什么，cancel 到底做了什么，为什么 WithTimeout 后面那句 defer cancel() 不是仪式感，而是资源释放动作。

事故通常不是从源码开始的

真实排查里，很少有人一上来就打开 context.go。

更常见的是这样的场景：

一个接口偶发超时。压测一上来，P99 开始抖，错误日志里出现 context deadline exceeded。你看监控，CPU 没打满，内存也没爆，但 goroutine 数不太对，一路往上爬。

然后你打开 pprof：

1

curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=1'

采样里有一批 goroutine 卡在业务 worker 上，等某个 channel，或者等 <-ctx.Done()。

这时候最危险的判断是：

“是不是 Go 的 context 泄漏了？”

大多数时候，不是。

更可能是你的调用链里少了三件事之一：创建了 timeout context 但没及时 cancel；启动了 goroutine 但没监听 ctx.Done()；或者监听了 Done，却没有确保取消路径真的跑到。