必须在函数可能阻塞、发起网络调用、启动goroutine或需响应取消时传入context.Context；纯内存计算无需ctx。错误做法是硬编码context.Background()，正确做法是由上层传入、下层传递并消费。
什么时候必须用 context.Context 传参
不是所有函数都需要加 context.Context 参数，只有当该函数可能阻塞、发起网络调用、启动 goroutine、或需要响应取消信号时，才需要显式接收并传递 ctx。比如数据库查询、HTTP 请求、定时任务、长轮询等场景。如果只是纯内存计算或立即返回的逻辑，加 context 反而增加耦合和干扰。
常见错误是把 context.Background() 或 context.TODO() 直接硬编码进业务函数内部——这会让调用方彻底失去控制权。正确做法是让上层决定传入什么 ctx，下层只负责消费和向下传递。
- HTTP handler 中应从请求中提取
r.Context()，而不是新建 - 数据库
QueryContext()、ExecContext()等方法必须传ctx，否则超时或取消无法生效 - 启动 goroutine 时，若需支持取消，应基于
ctx.Done()通道做退出判断，而非靠外部变量或 sleep 轮询
context.WithTimeout 和 context.WithDeadline 怎么选
WithTimeout 是相对时间，适合“最多执行 N 秒”这类需求；WithDeadline 是绝对时间点，适合“必须在某时刻前完成”的调度场景（如配合 cron 或分布式锁续期）。两者都会自动创建子 Context 并在到期时关闭 Done() 通道。
注意：超时后原 ctx 不会自动 cancel，必须调用返回的 cancel 函数释放资源。漏掉 defer cancel() 是高频 bug，会导致 goroutine 泄露或 timer 持续占用内存。
立即学习“go语言免费学习笔记（深入）”；
- 用
WithTimeout时，时间精度受系统调度影响，实际延迟可能略大于设定值 -
WithDeadline的时间点若早于当前时间，会立刻触发 cancel，ctx.Err()返回context.DeadlineExceeded - 不要对同一个
ctx多次调用WithTimeout——子 context 的 deadline 是叠加的，容易误判
为什么 context.WithValue 要慎用
WithValue 仅适用于传递请求范围的、不可变的元数据（如用户 ID、请求 trace ID、语言偏好），且键类型必须是自定义未导出类型，避免与其他包冲突。它不是通用参数传递机制，更不是替代函数参数的捷径。
滥用 WithValue 会导致隐式依赖、调试困难、类型不安全。比如把 *sql.DB 或 http.Client 塞进 context，既违反 context 设计本意，又阻碍依赖注入和单元测试。
- 键类型推荐写成
type ctxKey string，然后定义const userKey ctxKey = "user" - 取值时务必做非空判断：
v, ok := ctx.Value(userKey).(User)，不能直接断言 - HTTP 中更推荐用中间件把必要字段解析后存入 context，而不是让每个 handler 自己 parse header
goroutine 中使用 context 的典型陷阱
在 goroutine 内部直接使用外部传入的 ctx 是安全的，但若 goroutine 生命周期长于父 context，必须确保它监听 ctx.Done() 并及时退出。否则即使父请求已关闭，goroutine 仍可能持续运行，消耗 CPU 或 hold 住连接。
另一个常见问题是：在循环中反复创建子 context（如每轮重试都 WithTimeout），却没在每次迭代后调用 cancel，导致大量 timer 和 channel 泄露。
- goroutine 启动后，应立即检查
ctx.Err() != nil，再决定是否继续 - 使用
select等待ctx.Done()或业务事件，避免用for { if ctx.Err() != nil { break } }这种 busy-wait - 若 goroutine 需要主动取消下游操作，应使用
context.WithCancel(parent)创建新 context，并在适当时机调用cancel()
真正难的不是学会怎么调用那几个 WithXXX 函数，而是判断某个函数是否该暴露 ctx 参数、何时该自己创建子 context、以及 cancel 函数到底该在哪儿调。这些决策往往藏在并发模型和错误恢复路径里，而不是语法层面。
