17370845950

Golang context标准库如何使用_Golang上下文控制说明
context 用于控制 goroutine 生命周期和传递取消信号;必须传入 context.Context 的场景包括调用显式接受该参数的函数(如 QueryContext)、HTTP handler 中发起下游请求、启动需受控的子 goroutine 等。

context 不是用来传业务数据的,它是用来控制 goroutine 生命周期和传递取消信号的。

什么时候必须用 context.Context

当你调用的函数或方法明确接受

ctx context.Context 参数时,就必须传——比如 http.NewRequestWithContextdatabase/sql.Conn.QueryContextnet/http.Server.Serve 的 handler 签名里带 context.Context。这些底层实现依赖 ctx.Done() 通道来响应取消或超时。

  • HTTP handler 中需要主动发起下游请求(如调用另一个 API)时,应把入参 req.Context() 传下去,否则上游中断(如客户端断开)无法传播到底层
  • 启动子 goroutine 做异步工作且需受主流程控制时,必须传 context.WithCancelcontext.WithTimeout 派生的 ctx,否则 goroutine 可能泄漏
  • 数据库查询、文件读写、RPC 调用等阻塞操作,若支持 Context 版本,优先用 xxxContext 方法,避免死等

context.WithCancelcontext.WithTimeout 怎么选?

两者都返回 (context.Context, context.CancelFunc),区别在于触发取消的条件:WithCancel 需手动调用 cancel 函数;WithTimeout 在时间到达后自动调用 cancel。

  • WithCancel:当逻辑上存在“主动退出”条件,比如收到某个信号、某个 channel 关闭、状态机进入终态
  • WithTimeout:绝大多数网络 I/O 场景,例如 “最多等 5 秒”,它本质是 WithDeadline(time.Now().Add(5 * time.Second))
  • 别用 WithTimeout(0) 或极小值(如 1ns),这会导致上下文几乎立即取消,容易引发非预期失败
  • cancel 函数必须调用,且建议用 defer cancel(),但要注意:如果父 context 已取消,再调用子 cancel 不会 panic,但也没效果

为什么不能把值塞进 context.WithValue 当全局变量用?

context.WithValue 是为传递请求范围的、不可变的元数据设计的(如用户 ID、trace ID、认证 token),不是为替代参数或配置项。

  • 值类型必须是可比较的,且建议用自定义 key 类型(如 type ctxKey string),避免字符串 key 冲突
  • 不要传指针、函数、接口或大结构体——context 可能在多个 goroutine 间传递,值拷贝成本和并发安全风险会上升
  • 下游必须用 value, ok := ctx.Value(myKey).(MyType) 判断是否存在,不能假设一定有值;一旦漏判,可能 panic 或逻辑错乱
  • 常见误用:把 logger、DB 连接、配置对象塞进去——这些该通过函数参数或依赖注入传,而不是藏在 context 里

goroutine 泄漏最常踩的坑是什么?

最典型的是:派生了子 context,启了 goroutine,但没在合适时机调用 cancel,或 cancel 被 defer 在错误的作用域里。

  • 在 for-select 循环中监听 ctx.Done() 时,忘记 break 或 return,导致循环继续执行,goroutine 无法退出
  • go func() { ... }() 启动匿名 goroutine,但没把 ctx 作为参数传进去,导致它完全不受控制
  • 在 HTTP handler 里用 context.WithTimeout(r.Context(), ...),但 handler 返回后没调用 cancel——其实这时父 context(r.Context())已结束,子 cancel 是空操作;真正该 cancel 的是自己新启的子 goroutine 所用的子 context
  • 把 cancel 函数传给其他包或模块,又没文档说明“调用者负责 cancel”,结果谁都不调

context 的 cancel 传播是单向的(父→子),且不可逆;一旦被 cancel,所有子 context 的 Done() 都会关闭,但反过来不行。这个模型简单,但也意味着你得清楚每一层是谁派生的、谁该负责终止。