context 用于控制 goroutine 生命周期和传递取消信号;必须传入 context.Context 的场景包括调用显式接受该参数的函数(如 QueryContext)、HTTP handler 中发起下游请求、启动需受控的子 goroutine 等。
context 不是用来传业务数据的,它是用来控制 goroutine 生命周期和传递取消信号的。
context.Context?当你调用的函数或方法明确接受 参数时,就必须传——比如 
http.NewRequestWithContext、database/sql.Conn.QueryContext、net/http.Server.Serve 的 handler 签名里带 context.Context。这些底层实现依赖 ctx.Done() 通道来响应取消或超时。
req.Context() 传下去,否则上游中断(如客户端断开)无法传播到底层context.WithCancel 或 context.WithTimeout 派生的 ctx,否则 goroutine 可能泄漏Context 版本,优先用 xxxContext 方法,避免死等context.WithCancel 和 context.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),这会导致上下文几乎立即取消,容易引发非预期失败defer cancel(),但要注意:如果父 context 已取消,再调用子 cancel 不会 panic,但也没效果context.WithValue 当全局变量用?context.WithValue 是为传递请求范围的、不可变的元数据设计的(如用户 ID、trace ID、认证 token),不是为替代参数或配置项。
type ctxKey string),避免字符串 key 冲突value, ok := ctx.Value(myKey).(MyType) 判断是否存在,不能假设一定有值;一旦漏判,可能 panic 或逻辑错乱最典型的是:派生了子 context,启了 goroutine,但没在合适时机调用 cancel,或 cancel 被 defer 在错误的作用域里。
ctx.Done() 时,忘记 break 或 return,导致循环继续执行,goroutine 无法退出go func() { ... }() 启动匿名 goroutine,但没把 ctx 作为参数传进去,导致它完全不受控制context.WithTimeout(r.Context(), ...),但 handler 返回后没调用 cancel——其实这时父 context(r.Context())已结束,子 cancel 是空操作;真正该 cancel 的是自己新启的子 goroutine 所用的子 contextcontext 的 cancel 传播是单向的(父→子),且不可逆;一旦被 cancel,所有子 context 的 Done() 都会关闭,但反过来不行。这个模型简单,但也意味着你得清楚每一层是谁派生的、谁该负责终止。