context.WithCancel适用于需外部信号手动终止goroutine的场景，返回可调用cancel()的Context；子goroutine必须监听ctx.Done()以防泄漏，cancel函数应只调用一次且勿传给不可控第三方库。
context.WithCancel 适合手动终止正在运行的 goroutine
当需要外部信号（比如用户中断、超时前主动取消）来停止一组并发任务时，context.WithCancel 是最直接的选择。它返回一个可主动调用 cancel() 的 Context 和对应的取消函数。
常见错误是只在主 goroutine 调用 cancel()，却没确保子 goroutine 检查 ctx.Done() 并及时退出——这会导致 goroutine 泄漏。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有子 goroutine 必须在循环或关键阻塞点（如
select）中监听<code>ctx.Done() - 取消函数应只调用一次；重复调用无害但没必要，且可能掩盖逻辑错误
- 不要把
cancel函数传给不受控的第三方库，除非明确其会调用它 - 示例片段：
ctx, cancel := context.WithCancel(context.Background()) go func() { defer cancel() // 某些场景下可在此处触发取消 }() select { case <-ctx.Done(): return ctx.Err() // 如 context.Canceled }
context.WithTimeout 更适合有明确截止时间的批量请求
HTTP 客户端调用、数据库查询、微服务间 RPC 等场景，通常要求“最多等 N 秒”，这时 context.WithTimeout 比手写定时器 + WithCancel 更安全、更不易出错。
立即学习“go语言免费学习笔记（深入）”；
注意：超时时间从调用 WithTimeout 那一刻开始计时，不是从任务真正启动时算起。如果任务启动前有较长初始化（如连接池建立、配置加载），实际可用执行时间会少于预期。
实操建议：
- 超时值建议预留缓冲，比如依赖服务 SLA 是 800ms，设为 1200ms 更稳妥
- 避免在循环内反复创建新
Timeoutcontext，容易触发大量 timer 对象，影响 GC - 若需“总耗时限制”而非“单次调用限制”，应在顶层统一控制，而不是每个子任务单独设超时
子 context 的 Done channel 不会重复关闭，但必须被显式监听
ctx.Done() 返回的是一个只读 channel，它会在 context 被取消或超时时被关闭。这个 channel 只关闭一次，不会因多次 cancel 而 panic 或重复关闭。
但很多人误以为只要父 context 取消，所有子 goroutine 就会自动停止——其实不会。Go 没有强制中断机制，一切依赖你是否在关键路径上检查 <code>ctx.Done()。
实操建议：
- 不要用
if ctx.Err() != nil替代select监听ctx.Done()，前者无法捕获中间状态（如刚取消但还没 propagate 到子 context） - 在阻塞 I/O（如
http.Client.Do）、channel 操作、time.Sleep 前，优先用select包裹，避免死等 - 自定义函数接收
context.Context参数时，应文档化说明它是否响应取消，以及响应延迟的大致范围
WithValue 不能替代参数传递，也不该用来传取消逻辑
context.WithValue 常被误用作“跨层传参”工具，比如把 traceID、user ID 或数据库连接塞进去。但它设计初衷只是传请求范围的元数据（request-scoped metadata），且 key 类型必须是 unexported 类型，否则极易冲突。
更严重的问题是：有人试图用 WithValue 把 cancel 函数塞进 context，再让下游调用它——这破坏了控制流的清晰性，也违背了 context 的只读语义。
实操建议：
- 传业务参数请用函数参数，不要藏在 context 里；只有真正属于“请求上下文”的、非功能性的值才考虑
WithValue - key 应定义为私有 struct 或 interface{}，避免字符串 key 冲突：
type ctxKey string const userKey ctxKey = "user"
- 永远不要在 context 中存可变对象（如 map、slice），因为多个 goroutine 并发读写会引发 data race
WithCancel 或 WithTimeout，而是判断哪些 goroutine 必须响应取消、在哪儿检查 Done()、以及如何让取消信号准确反映业务语义——比如“取消上传”和“取消重试”应触发不同清理行为，这些都得靠你自己编码实现。 
