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(), ...)—— 这等于切断了调用链的生命周期控制
