context.WithCancel/Timeout/Deadline/Value 到底该怎么用才对？

context核心是传递取消信号、超时控制和请求生命周期边界，非传参工具；WithCancel用于手动取消场景，须调用cancel()；WithTimeout/WithDeadline需确保操作响应取消；WithValue仅存不可变元数据，禁传业务参数；context须自上而下传递。 Go 里的 不是用来“传参”的，也不是为了替代函数参数；它的核心职责是 传递取消信号、超时控制和跨 goroutine 的请求生命周期边界 。用错 context，轻则逻辑混乱、资源泄漏，重则服务雪崩、goroutine 泄漏。下面说清楚每个方法该在什么场景下用、怎么用才对。 WithCancel：只在需要手动触发取消时才用 它返回一个可主动关闭的 context，适合“外部控制流程终止”的场景，比如用户主动取消请求、管理后台下发停机指令、或组合多个子任务并统一中止。 不要为每个函数调用都 new 一个 WithCancel —— 没有取消需求就直接用 或上游传入的 ctx 必须调用返回的 函数，否则底层 channel 不会关闭，goroutine 和 timer 可能永远卡住 典型误用：在 HTTP handler 里自己调 ，却不跟 request 生命周期绑定 → 应该用 ，它已自带 cancel（当连接断开或客户端取消时自动触发） WithTimeout / WithDeadline：按时间约束做自动清理，不是“设个保险丝”就完事 两者本质一样， 是相对当前时间的偏移， 是绝对时间点。关键不是“加个 timeout”，而是 确保所有依赖此 context 的操作真正响应取消 。 HTTP Client 发起请求时，应把带 timeout 的 context 传给 ，而不是只在函数开头 Sleep 一下 数据库查询、RPC 调用、channel receive 等阻塞操作，必须显式检查 并退出，不能只靠 defer 关闭资源 避免嵌套 timeout：比如外层用 5s，内层又用 3s —— 容易导致提前中断且难以 debug；优先统一由最外层控制超时边界 WithValue：只存元数据，绝不传业务参数或状态对象 是 context 里最危险的一个。它不参与取消、不携带时间信息，只是个“附带注释”。滥用会导致隐式依赖、类型难维护、甚至内存泄漏。 只允许存不可变、小体积、请求级只读元数据，比如 、 、 禁止传 struct 指针、函数、*sql.DB、配置对象等 —— 这些应该通过参数或依赖注入传递 取值时务必用类型断言 + 判断是否为 nil，不要假设 key 一定存在；key 类型建议用私有 unexported 类型，避免冲突 常见反例：“我把 config 放 context 里，全链路都能取” → 这会让函数签名失真，单元测试困难，也违背依赖显式化原则 组合使用的关键原则：从上往下传，不从下往上造 context 树必须是单向向下传递的。父 goroutine 创建 context，子 goroutine 接收并可能派生新 context（如加 timeout），但绝不在子 goroutine 里凭空 new Background 或 WithCancel。 HTTP server：handler 接收 → 传给 service 层 → service 再根据 DB 调用需要加 定时任务：用 启动，收到 OS 信号后调 ，让所有子任务感知退出 永远不要在工具函数里写 —— 这等于切断了调用链的生命周期控制