第26篇 Context包取消、超时与值传递摘要Context是Go并发控制的核心组件负责取消信号传播、超时控制和请求作用域值传递。本文从一次雪崩故障说起讲透Context的四种派生方式和常见误用。一次请求雪崩去年双十一压测我们的订单服务突然整片超时。上游网关的请求超时设了3秒但下游库存服务有个慢查询偶尔要8秒。正常情况下单个慢请求不该拖垮整个服务问题出在我们的处理逻辑没有做超时控制。当时每个HTTP请求会起几个goroutine去并行查库存、查物流、查优惠券。如果库存查询卡住了这个请求的goroutine就一直挂着等下游响应。上游网关3秒超时断开连接但我们这边的goroutine还在傻等占着连接池不释放。请求量一上来连接池耗尽整个服务雪崩。根因就是缺少超时控制而且即使上游取消了下游的goroutine也收不到信号还在白干活。Context 包就是来解决这个问题的。Context的四种派生方式Context 的核心思路是树形派生。所有Context从一个根节点派生出来父节点取消时所有子节点自动取消。packagemainimport(contextfmttime)funcmain(){// Background是根Context通常在main或顶层使用ctx:context.Background()// 1. WithCancel 手动取消cancelCtx,cancel:context.WithCancel(ctx)// 用完必须调用cancel释放资源defer是标准写法defercancel()// 2. WithTimeout 超时自动取消// 3秒后cancelCtx2会自动取消timeoutCtx,cancel2:context.WithTimeout(ctx,3*time.Second)defercancel2()// 3. WithDeadline 在指定时间点取消// 和WithTimeout类似区别是传绝对时间而非相对时长deadlineCtx,cancel3:context.WithDeadline(ctx,time.Now().Add(5*time.Second))defercancel3()// 4. WithValue 携带请求作用域的值// 把traceID放进context下游函数可以取出来打日志valCtx:context.WithValue(ctx,traceID,req-abc-123)// 四种派生方式可以随意组合嵌套_cancelCtx_timeoutCtx_deadlineCtx_valCtx fmt.Println(四种Context派生方式创建完成)}这四种方式可以嵌套派生。比如先 WithTimeout 创建超时控制再在它基础上 WithValue 携带请求信息形成一个Context链。父节点取消时信号会沿着链向下传播。超时控制实战来看一个实际场景HTTP处理函数里并行请求多个下游服务每个都要受超时控制。packagemainimport(contextfmtnet/httptime)// fetchUserInfo 模拟调用下游服务获取用户信息// 第一个参数必须是context这是Go的惯例funcfetchUserInfo(ctx context.Context,userIDint)(string,error){// 用select监听ctx.Done和业务逻辑// ctx超时或取消时Done通道关闭select立即走这个caseselect{case-time.After(2*time.Second):// 模拟2秒的处理耗时returnfmt.Sprintf(user-%d-info,userID),nilcase-ctx.Done():// 超时或被取消return,ctx.Err()// 返回context的错误}}funcuserHandler(w http.ResponseWriter,r*http.Request){// 给整个请求设置3秒超时// 从请求开始计时到3秒自动取消所有派生的子contextctx,cancel:context.WithTimeout(r.Context(),3*time.Second)defercancel()// 确保资源释放// 并行发起下游调用typeresultstruct{valstringerrerror}ch:make(chanresult,1)// 带缓冲避免goroutine泄漏gofunc(){val,err:fetchUserInfo(ctx,1001)// 传入带超时的ctxch-result{val,err}}()// 等待结果或整体超时select{caseres:-ch:ifres.err!nil{http.Error(w,res.err.Error(),http.StatusInternalServerError)return}fmt.Fprintf(w,got %s\n,res.val)case-ctx.Done():// 整体超时触发http.Error(w,request timeout,http.StatusGatewayTimeout)}}funcmain(){http.HandleFunc(/user,userHandler)fmt.Println(服务启动在 :8080)http.ListenAndServe(:8080,nil)}关键点在于 fetchUserInfo 里的 select。即使下游服务卡住只要 ctx 超时Done 通道关闭goroutine 就能及时退出不会泄漏。这就是 Context 级联取消的威力一个超时信号能沿着调用链传播到最底层。独家踩坑WithCancel不调用cancel会泄漏这个坑我见过很多次包括我自己也踩过。WithCancel 返回的 cancel 函数如果不调用对应的 context 和它派生的所有子 context 都不会被垃圾回收因为它们被内部的定时器或 propagateCancel 机制引用着。// 错误示范漏掉cancelfuncbadHandler(ctx context.Context){// 每次调用都派生新context但从不cancel_,cancel:context.WithCancel(ctx)_cancel// 忘记调用或者提前return了// goroutine泄漏context引用链不会被回收}更隐蔽的是 WithTimeout它内部启动了一个定时器。即使请求正常返回如果不调用 cancel定时器会一直跑到超时时间才释放。在高QPS服务里这会导致定时器堆积内存缓慢上涨。// 正确写法defer cancel是铁律funcgoodHandler(ctx context.Context){ctx,cancel:context.WithTimeout(ctx,3*time.Second)defercancel()// 无论正常返回还是panic都会执行// ... 业务逻辑}有一次排查线上内存泄漏pprof 看到大量 time.Timer 对象最后定位到就是一处漏了 cancel。加上 defer cancel 之后内存曲线立刻平稳了。从那以后我定了个规矩代码评审时只要看到 context.With 开头的函数第一件事就是确认下面有没有 defer cancel。值传递的边界WithValue 经常被滥用有人拿它当全局变量传递业务参数这其实违背了设计初衷。Context 里的值应该是请求作用域的元数据比如 traceID、租户ID、认证信息不该传业务实体。// 用自定义类型做key避免冲突typectxKeystringconst(keyTraceID ctxKeytraceIDkeyTenant ctxKeytenant)// 封装存取函数类型安全funcwithTraceID(ctx context.Context,idstring)context.Context{returncontext.WithValue(ctx,keyTraceID,id)}functraceID(ctx context.Context)string{v,_:ctx.Value(keyTraceID).(string)// 类型断言returnv}用自定义类型做 key 能避免和其他包冲突。裸字符串做 key 是常见的坑两个包都用 “id” 做 key值就会互相覆盖排查起来非常痛苦。对比分析取消控制有两种方式Context 和裸 channel来对比一下。维度Context裸channel级联取消自动传播到所有子节点需手动层层传递超时控制内置WithTimeout要自己管time.After值传递WithValue内置要额外加字段错误信息ctx.Err()区分原因只有关闭信号标准化全生态通用各写各的Context 的优势在于标准化和自动级联。裸 channel 在简单场景更直观但一旦涉及多层调用和超时组合自己管理成本很高还容易漏。总结预告Context 是 Go 并发的神经系统取消信号沿着调用树自动传播超时控制内置且准确。记住两条铁律一是任何派生的 context 都要 defer cancel二是 WithValue 只传请求元数据别传业务参数。下一篇进入并发模式篇先讲 Worker Pool这是控制并发度最实用的模式。