Context包中WithCancel/Timeout/Deadline/Value怎么正确使用？

context核心是传递取消信号、超时控制和请求生命周期边界，非传参工具；WithCancel用于手动取消场景，须调用cancel()；WithTimeout/WithDeadline需确保操作响应取消；WithValue仅存不可变元数据，禁传业务参数；context须自上而下传递。

Go 里的 context 不是用来“传参”的，也不是为了替代函数参数；它的核心职责是传递取消信号、超时控制和跨 goroutine 的请求生命周期边界。用错 context，轻则逻辑混乱、资源泄漏，重则服务雪崩、goroutine 泄漏。下面说清楚每个方法该在什么场景下用、怎么用才对。

WithCancel：只在需要手动触发取消时才用

它返回一个可主动关闭的 context，适合“外部控制流程终止”的场景，比如用户主动取消请求、管理后台下发停机指令、或组合多个子任务并统一中止。

• 不要为每个函数调用都 new 一个 WithCancel —— 没有取消需求就直接用 context.Background() 或上游传入的 ctx
• 必须调用返回的 cancel() 函数，否则底层 channel 不会关闭，goroutine 和 timer 可能永远卡住
• 典型误用：在 HTTP handler 里自己调 WithCancel，却不跟 request 生命周期绑定 → 应该用 r.Context()，它已自带 cancel（当连接断开或客户端取消时自动触发）

WithTimeout / WithDeadline：按时间约束做自动清理，不是“设个保险丝”就完事

两者本质一样，WithTimeout 是相对当前时间的偏移，WithDeadline 是绝对时间点。关键不是“加个 timeout”，而是确保所有依赖此 context 的操作真正响应取消。

• HTTP Client 发起请求时，应把带 timeout 的 context 传给 client.Do(req.WithContext(ctx))，而不是只在函数开头 Sleep 一下
• 数据库查询、RPC 调用、channel receive 等阻塞操作，必须显式检查 ctx.Done() 并退出，不能只靠 defer 关闭资源
• 避免嵌套 timeout：比如外层用 5s，内层又用 3s —— 容易导致提前中断且难以 debug；优先统一由最外层控制超时边界

WithValue：只存元数据，绝不传业务参数或状态对象

WithValue 是 context 里最危险的一个。它不参与取消、不携带时间信息，只是个“附带注释”。滥用会导致隐式依赖、类型难维护、甚至内存泄漏。

• 只允许存不可变、小体积、请求级只读元数据，比如 request_id、user_id、trace_id
• 禁止传 struct 指针、函数、*sql.DB、配置对象等 —— 这些应该通过参数或依赖注入传递
• 取值时务必用类型断言 + 判断是否为 nil，不要假设 key 一定存在；key 类型建议用私有 unexported 类型，避免冲突
• 常见反例：“我把 config 放 context 里，全链路都能取” → 这会让函数签名失真，单元测试困难，也违背依赖显式化原则

组合使用的关键原则：从上往下传，不从下往上造

context 树必须是单向向下传递的。父 goroutine 创建 context，子 goroutine 接收并可能派生新 context（如加 timeout），但绝不在子 goroutine 里凭空 new Background 或 WithCancel。

• HTTP server：handler 接收 r.Context() → 传给 service 层 → service 再根据 DB 调用需要加 WithTimeout
• 定时任务：用 context.WithCancel(context.Background()) 启动，收到 OS 信号后调 cancel()，让所有子任务感知退出
• 永远不要在工具函数里写 ctx := context.WithTimeout(context.Background(), ...) —— 这等于切断了调用链的生命周期控制