Context传递须从入口开始，中途创建会切断取消链；I/O操作需传入context；WithTimeout用于相对超时，WithDeadline用于绝对截止；WithValue仅存请求元信息；cancel函数必须且只能调用一次。
Context 传递必须从入口函数开始，不能中途创建
Go 的 context.Context 是不可变的，所有派生操作（如 WithCancel、WithTimeout）都返回新实例。如果在业务逻辑中间突然调用 context.Background() 或 context.TODO()，就等于切断了上游的取消链和超时控制——下游 goroutine 不会随 HTTP 请求结束或父任务取消而退出。
常见错误现象：http: Handler timeout 日志没出现，但请求已返回，后台 goroutine 仍在运行；或者单元测试因 goroutine 泄漏失败。
实操建议：
- HTTP handler 中，直接使用入参的
r.Context()，不要自己 new - CLI 命令入口（如 cobra）中，用
cmd.Context()，而非context.Background() - 数据库查询、RPC 调用、文件读写等 I/O 操作，一律把 context 作为第一个参数传入（如
db.QueryContext(ctx, ...)）
WithTimeout 和 WithDeadline 的选择取决于时间语义
WithTimeout 是相对时间，基于当前系统时钟计算；WithDeadline 是绝对时间点。两者行为不同，选错会导致超时提前触发或完全不生效。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
- 对外部服务发起一次 HTTP 请求，预期最多等 5 秒 → 用
context.WithTimeout(ctx, 5*time.Second) - 整个请求处理必须在 2024-10-15T14:30:00Z 前完成（比如配合分布式调度 deadline）→ 用
context.WithDeadline(ctx, t)
容易踩的坑：在循环中反复调用 WithTimeout，每次都会重置计时起点；正确做法是只在入口处设一次，让所有子操作共享同一个 deadline。
Value 类型数据应严格限制为请求元信息，不可用于业务状态
context.WithValue 是唯一能往 Context 塞自定义数据的方法，但它不是 Go 推荐的“传参方式”。它的设计初衷是传递跨层的、只读的请求范围元数据（如用户 ID、trace ID、locale），不是替代函数参数或结构体字段。
为什么这样做：
- 类型安全丢失：取值时需强制类型断言，容易 panic
- 调试困难：无法静态分析哪些地方读写了哪个 key
- 内存泄漏风险：若 value 是大对象且 context 生命周期过长（如被缓存），会阻碍 GC
实操建议：
- 定义 key 时用私有未导出类型（如
type ctxKey string），避免与其他包冲突 - 只存小而稳定的值，例如
ctx.Value(userKey).(int64)，不要塞*User结构体指针 - 关键业务参数（如 orderID、tenantID）优先走显式函数参数
cancel 函数必须被调用，且只能调用一次
由 context.WithCancel、WithTimeout、WithDeadline 返回的 cancel 函数，本质是释放内部 timer 和 channel 的资源。漏调用会导致 goroutine 和 timer 泄漏；重复调用会 panic（panic: sync: negative WaitGroup counter 或 context canceled 相关异常）。
性能影响：未调用 cancel 的 timer 会持续运行直到超时，占用系统资源；在高并发短生命周期请求中尤为明显。
实操建议：
- 用
defer cancel()，但确保 defer 发生在 goroutine 启动前（否则可能在父 goroutine 结束后才执行） - 若启动子 goroutine 处理异步任务，应在子 goroutine 内部调用 cancel（或通过 channel 通知主 goroutine）
- 检查是否已有第三方库帮你调用了 cancel（例如
http.Client.Do内部会调用，你不需要再 wrap 一层 cancel）
最常被忽略的是：在 error early return 路径中忘记 defer，或把 defer 放在 if err != nil {} 之后导致跳过。
