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。它们只是把一段调用生命周期交给更底层的数据库调用。

为什么很多团队的内部 API，早就不该只用 REST 了

Tue, 14 Apr 2026 11:30:00 +0800

服务越写越多，接口越写越拧巴。

明明是 approveInvoice() 这种动作，却要硬拗成 POST /invoices/{id}/approval。

文档越来越厚，新来的同事越看越迷糊——这到底是资源操作，还是动作调用？

很多团队的问题，不是不会做 API，而是一开始就把内部系统也按公共 API 那套方式设计了。

API 设计 on Zampo Blog

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

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

为什么很多团队的内部 API，早就不该只用 REST 了