Go 为什么宁可让你多传一个 ctx 参数

Wed, 20 May 2026 22:20:00 +0800

很多 Go 开发者第一次系统用 context，都会嫌它啰嗦。

一个请求从 handler 进来，service 要传 ctx，repo 要传 ctx，RPC client 要传 ctx，连中间那些根本不关心超时和取消的函数，也要机械地把 ctx 往下递。

看多了以后，很自然会冒出一个问题：为什么不能像 Java、Node.js、Python 那样，把上下文放进运行时里？

Java 有 ThreadLocal。Node.js 有 AsyncLocalStorage。Python 有 contextvars。它们都能让深层函数不改签名，也拿到当前请求的 trace id、用户信息、日志上下文。

Go 偏不。

它宁可让你在函数签名里多写一个参数：

1
2
3


func DoSomething(ctx context.Context, arg Arg) error {
 // ...
}

这不是因为 Go 不知道隐式上下文更省事。恰好相反，这正是 Go 的取舍：它愿意把“不优雅”摆在台面上，换调用链里的生命周期可见。

显式传参，最先付出的就是签名噪音

先承认代价。

ctx context.Context 作为首参，会污染函数签名。尤其在分层很深的服务里，中间层经常只是 pass-through：自己不用 ctx，但必须接住它，再传给下一层。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


func (h *Handler) Create(ctx context.Context, req CreateReq) error {
 return h.service.Create(ctx, req)
}

func (s *Service) Create(ctx context.Context, req CreateReq) error {
 return s.repo.Insert(ctx, req.UserID, req.Payload)
}

func (r *Repo) Insert(ctx context.Context, userID string, payload []byte) error {
 _, err := r.db.ExecContext(ctx, `insert into ...`, userID, payload)
 return err
}

这段代码里，Handler 和 Service 可能都没有真正“使用” ctx。它们只是把一段调用生命周期交给更底层的数据库调用。

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，却没有确保取消路径真的跑到。

并发 on Zampo Blog

Go 为什么宁可让你多传一个 ctx 参数

显式传参，最先付出的就是签名噪音

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

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