必须在函数可能阻塞、发起网络调用、启动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 持续占用内存。
- 用
WithTimeout时，时间精度受系统调度影响，实际延迟可能略大于设定值 -
WithDeadline的时间点若早于当前时间，会立刻触发 cancel，ctx.Err()返回context.DeadlineExceeded - 不要对同一个
ctx多次调用WithTimeout——子 context 的 deadline 是叠加的，容易误判
为什么 context.WithValue 要慎用
WithValue 仅适用于传递请求范围的、不可变的元数据（如用户 ID、请求 trace ID、语言偏好），且键类型必须是自定义未导出类型，避免与其他包冲突。它不是通用参数传递机制，更不是替代函数参数的捷径。
