Context on DK Blog

Go context 不是万能取消器：超时、泄漏和传参边界

Fri, 12 Dec 2025 21:12:00 +0800

context.Context 是 Go 服务端代码里很常见的东西。HTTP 请求、数据库查询、RPC 调用、后台任务，基本都会带一个 ctx。

但用久了会发现，context 不是万能取消器。它只是一个信号传递机制，真正停不停，还得看代码有没有响应它。

我现在看 context 代码，会先问一个问题：取消信号最后有没有传到真正阻塞的地方？如果只是函数签名里层层带了 ctx，但最里面的网络请求、数据库查询、channel 等待没有监听它，那这个 context 基本只是摆设。

超时要放在调用边界

比如一个 HTTP handler 里调用下游接口，我通常会在下游调用边界设置超时：

1
2
3
4
5
6


func (s *Service) FetchProfile(ctx context.Context, userID int64) (*Profile, error) {
 ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
 defer cancel()

 return s.client.GetProfile(ctx, userID)
}

这里的 defer cancel() 不是摆设。即使请求提前返回，也要释放 context 相关资源。

但超时不是越短越好。超时应该根据调用链来设计：入口总超时、数据库超时、外部 API 超时都要有层级关系。否则外层 3 秒，内层 5 秒，就会出现配置看起来有超时，但实际没意义的情况。

我一般会让超时从外到内逐层收紧：

1
2
3
4


HTTP request timeout: 5s
service orchestration: 4s
database query: 2s
external API call: 1500ms

这样做不是为了凑数字，而是避免内层还在等，外层已经没法返回。超时策略如果没有层级，排查时会非常乱。

goroutine 不会因为 ctx 取消自动退出

这是最容易误会的地方。

下面这段代码里，如果 goroutine 内部不监听 ctx.Done()，取消 context 也没用：

1
2
3
4
5


go func() {
 for {
 doSomething()
 }
}()

应该显式处理退出信号：

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


go func() {
 ticker := time.NewTicker(time.Second)
 defer ticker.Stop()

 for {
 select {
 case <-ctx.Done():
 return
 case <-ticker.C:
 doSomething()
 }
 }
}()

context 只是告诉你“该停了”，不是强制把 goroutine 杀掉。

不要把 context 存进结构体里

我见过有人把 context 放进 service struct：

1
2
3


type Service struct {
 ctx context.Context
}

这个写法很容易把请求生命周期搞乱。Service 往往是长生命周期对象，而 context 通常属于一次请求、一次任务或一次调用。

更推荐这样：

1
2
3
4
5
6
7


type Service struct {
 repo *Repo
}

func (s *Service) CreateOrder(ctx context.Context, req CreateOrderRequest) error {
 return s.repo.Insert(ctx, req)
}

context 应该作为第一个参数显式传递，而不是藏在对象状态里。

WithValue 要克制

context.WithValue 可以传跨调用链的信息，但不适合传普通业务参数。

适合放的东西一般是：

request id。
trace id。
auth token 的解析结果，前提是项目里有明确约定。
日志字段里需要贯穿调用链的元信息。

不太适合放：

userID 这种业务函数必须显式依赖的参数。
查询条件。
配置项。
可选开关。

如果一个函数没有 userID 就无法工作，那它应该出现在函数签名里，而不是从 context 里偷偷取。

select 里也要注意阻塞点

有时代码写了 ctx.Done()，但还是取消不及时。原因可能是实际阻塞发生在另一个调用里。

1
2
3
4
5
6


select {
case <-ctx.Done():
 return ctx.Err()
default:
 return slowCall()
}

这里一旦进入 slowCall()，如果 slowCall 自己不支持 context，外层就没法及时取消。

更好的方式是让阻塞调用本身接收 context：

1

return slowCall(ctx)

数据库、HTTP 客户端、RPC 客户端通常都有对应的 context 版本。项目里自己封装库时，也应该把 context 继续传下去。

还有一种容易漏的场景是 channel 发送：

1
2
3
4
5
6


select {
case jobs <- job:
 return nil
case <-ctx.Done():
 return ctx.Err()
}

如果直接 jobs <- job，队列满的时候调用方就卡住了，外层取消也救不了。context 能不能生效，通常就差这一个 select。

我对 context 的理解越来越简单：它传递取消和超时信号，不负责强制停止 goroutine，不应该替代函数参数，应该从入口一路传到真正阻塞的调用点。

参考资料

Go 开发里的几个小技巧：defer、context、错误处理和日志边界

Mon, 27 Oct 2025 19:48:00 +0800

这篇不是系统教程，只是整理几个 Go 项目里经常会用到的小习惯。

这些点都不复杂，但如果一开始没想清楚，项目变大之后会很难受。

我以前觉得 Go 项目的“工程味”主要靠目录结构，后来发现更常出问题的是这些细节：资源释放放在哪、错误在哪一层补上下文、日志谁来打、context 到底传什么。它们单独看都很小，叠起来就是项目维护成本。

defer 不只是少写一行 Close

defer 最常见的用法是释放资源：

1
2
3
4
5


f, err := os.Open(name)
if err != nil {
 return err
}
defer f.Close()

这当然没问题，但有两个细节我后来比较注意。

第一个是循环里不要随手 defer。比如处理很多文件时，如果在循环里 defer close，文件句柄会等函数返回才释放，不是每次循环结束就释放。

1
2
3
4
5


for _, name := range names {
 if err := handleFile(name); err != nil {
 return err
 }
}

把单次处理拆到小函数里，反而更清楚。

第二个是 defer 里如果有错误，不要完全忽略。比如写文件时，Close 也可能返回错误。日志可以记，或者在需要时合并返回。

写文件时我会更谨慎一点，因为有些错误可能在 flush/close 时才暴露：

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


func writeFile(name string, data []byte) (err error) {
 f, err := os.Create(name)
 if err != nil {
 return err
 }
 defer func() {
 if closeErr := f.Close(); err == nil && closeErr != nil {
 err = closeErr
 }
 }()

 _, err = f.Write(data)
 return err
}

这个写法不是每个地方都需要，但在写配置、写导出文件、写临时产物时，我会比读文件更认真处理 Close。

context 只放请求生命周期相关的东西

context.Context 很好用，但也很容易被当成万能参数袋。

我现在比较坚持一个边界：context 里放取消信号、超时、trace id、request id 这类请求生命周期相关信息，不放业务参数。

不太推荐这样：

1

ctx = context.WithValue(ctx, "user_id", userID)

如果 userID 是业务逻辑必须显式依赖的东西，直接传参数更清楚：

1
2
3


func ListOrders(ctx context.Context, userID int64) ([]Order, error) {
 // ...
}

context 的价值是把取消、超时、跨调用链信息传下去，不是把函数签名藏起来。

错误处理要留住上下文

Go 里错误处理最容易写成这样：

1
2
3


if err != nil {
 return err
}

小函数里问题不大，但跨几层调用之后，最终日志只看到 connection refused，就不知道是哪一步失败了。

我更习惯在边界位置包一层上下文：

1
2
3


if err != nil {
 return fmt.Errorf("query user by id %d: %w", id, err)
}

然后在上层需要判断错误类型时，用 errors.Is 或 errors.As：

1
2
3


if errors.Is(err, sql.ErrNoRows) {
 return nil, ErrUserNotFound
}

这样既能保留原始错误，又能让日志里有足够线索。

日志边界不要太散

日志不是越多越好。很多项目的问题不是没日志，而是日志到处打，真正出问题时看不出主线。

我的习惯是：

入口层记录请求开始、结束、耗时和 trace id。
业务层只记录关键状态变化。
基础设施层返回带上下文的错误，不随便打 error 日志。
最外层统一把错误打出来。

否则一个错误从 DAO 层、service 层、handler 层各打一遍，日志系统里看起来像出了三个问题。

Go 1.21 之后标准库里有 log/slog，结构化日志更方便了。即使不用 slog，也建议日志字段固定下来，比如 request_id、user_id、method、path、latency_ms。

我会尽量避免这种日志：

1

log.Printf("failed: %v", err)

它的问题不是不能看，而是上下文太少。更好的方式是把动作、对象和链路字段带上：

1
2
3
4
5


logger.Error("create order failed",
 "user_id", userID,
 "request_id", requestID,
 "err", err,
)

日志的边界想清楚以后，错误包装和日志字段会互相配合，而不是每一层都打一遍。

小结

这些技巧都不算高级，但很影响项目长期维护：

defer 适合资源释放，但注意循环和 Close 错误。
context 传生命周期，不传业务参数。
错误返回要带动作上下文。
日志尽量在边界统一记录，不要每层都打一遍。

Go 的代码很多时候不是写不出来，而是写久了之后还能不能看懂。这个区别挺大。