Go context包专为控制生命周期和传递取消信号设计，不可用于传业务参数；必须用WithCancel的场景是需主动终止长期goroutine；WithTimeout基于相对时长，WithDeadline基于绝对时间点；WithValue仅适用于请求级只读元数据，业务参数应显式传递。
Go 的 context 包不是用来“传递参数”的，而是专为控制生命周期、传播取消信号和传递请求范围的只读值而设计；滥用它传业务数据或频繁修改会导致代码难维护、内存泄漏或 goroutine 泄漏。
什么时候必须用 context.WithCancel？
当你启动一个可能长期运行、且需要被外部主动终止的 goroutine 时，context.WithCancel 是最直接的手段。典型场景包括：HTTP 请求处理中启后台轮询、数据库连接池超时等待、长连接心跳协程。
- 调用
context.WithCancel返回的cancel函数必须在确定不再需要子 goroutine 时显式调用（比如 handler 返回前、defer 中） - 不调用
cancel→ 子 goroutine 持有父 context 引用 → 父 context 无法被 GC → 可能泄露内存和 goroutine - 同一个 context 被多次
cancel()是安全的，但无实际意义；重复 defercancel可能掩盖逻辑错误
示例：
ctx, cancel := context.WithCancel(r.Context())
defer cancel() // 必须放 handler 顶层 defer，不能只在某分支里
<p>go func() {
for {
select {
case <-ctx.Done():
return // 收到取消信号，退出
default:
// 执行工作
time.Sleep(1 * time.Second)
}
}
}()
context.WithTimeout 和 context.WithDeadline 的区别在哪？
二者都用于自动触发取消，但时间语义不同：WithTimeout 是相对当前时间的持续时长，WithDeadline 是绝对时间点。选错会导致超时行为不符合预期。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
context.WithTimeout(ctx, 5*time.Second)：从调用该函数那一刻起，5 秒后自动cancel -
context.WithDeadline(ctx, time.Now().Add(5*time.Second))：等价于上面；但如果传入的是已过期的 deadline（比如服务时钟漂移），会立即取消 - HTTP 客户端发起请求时推荐用
WithTimeout；定时任务调度或与外部系统约定截止时间时，优先考虑WithDeadline - 注意：子 context 的 timeout/timeout 不会叠加父 context 的 deadline —— 它们以最先到期者为准
为什么不能把业务参数塞进 context.WithValue？
context.WithValue 仅适用于传递“请求范围的、不可变的元数据”，比如用户 ID、trace ID、请求 locale。把它当成全局变量或状态容器，是 Go 社区公认的反模式。
- 类型不安全：取值时需强制类型断言，一旦 key 冲突或类型错配，运行时报 panic
- 破坏可测试性：函数依赖隐式 context 值，难以 mock 或单元测试
- 逃逸分析干扰：value 若是大结构体或含指针，可能引发不必要的堆分配
- 正确做法：业务参数应作为函数显式参数传入；若实在要透传（如中间件注入用户信息），定义明确的 key 类型（非
string），并配合文档说明生命周期
例如，不要这样写：
// ❌ 错误：用字符串 key，无类型保障
ctx = context.WithValue(ctx, "user_id", 123)
<p>// ✅ 推荐：定义私有类型 key
type userIDKey struct{}
ctx = context.WithValue(ctx, userIDKey{}, 123)HTTP Server 中 context 生命周期容易被忽略的细节
net/http 默认为每个请求生成一个 context，但它**不会自动随 handler 返回而取消**——取消动作由你控制，且只影响你显式派生出的子 context。
-
r.Context()在 handler 返回后仍可能存活一小段时间（直到底层连接复用或关闭），但其Done()channel 已关闭，不可再用于派生新子 context - 不要在 handler 返回后继续使用
r.Context()启动新 goroutine，否则可能 panic 或行为未定义 - 如果 handler 中调用了下游 HTTP client，务必把
r.Context()传给http.Client.Do，否则超时和取消信号无法透传 - 中间件中修改 context（如加 value）没问题，但别覆盖原
Context()方法，否则破坏 http.Server 内部逻辑
真正危险的是：以为“request 结束 context 就自动销毁”，结果在 defer 里还拿它做异步清理，或在 goroutine 里继续监听 Done() —— 这些地方早已失效。
