Go语言Context上下文传递：语言学习中的超时与取消控制

必须。context.WithTimeout 返回的 cancel 函数用于释放底层 timer 和 goroutine，不调用会导致资源泄漏；HTTP 请求需确保 client.Do 接收带 context 的 *http.Request；监听取消必须用 select <-ctx.Done()，不能轮询 ctx.Err()。

context.WithTimeout 必须配 defer cancel() 吗？

必须。context.WithTimeout 返回的 cancel 函数不是可选配件，而是资源释放的关键一环。

原因在于：超时触发后，Done() 通道关闭、Err() 返回 context.DeadlineExceeded，但底层 time.Timer 和其 goroutine 并未自动停止——它们仍持有引用，持续运行，直到被显式清理。

• 不调用 cancel() → 定时器泄漏，goroutine 持续占用内存和调度资源
• 只在超时后才调用 → 依然晚了，泄漏已发生
• 正确姿势：始终用两个变量接收，且在作用域末尾加 defer cancel()，哪怕任务提前完成或出错也要执行

HTTP 请求中 context 不生效的常见写法

最典型的失效场景是：改了请求对象的 context，却没让 http.Client.Do 真正感知到它。

http.Client 自身的 Timeout 字段无法覆盖 DNS 解析、TLS 握手、连接池等待等环节；只有传入 context 才能统一控制全链路。

立即学习“go语言免费学习笔记（深入）”；

• 错误写法：req = req.WithContext(ctx)，然后调用 client.Do(req) —— 此时 ctx 对请求完全无效
• 正确写法：client.Do(req.WithContext(ctx))，或先赋值再调用，确保 Do 内部读取的是带 context 的 *http.Request
• 额外注意：http.Transport 的 IdleConnTimeout、DialContext 等字段也需配合 context 使用，否则连接建立阶段仍可能卡死

监听取消信号只能用 select，不能 if ctx.Err() != nil

ctx.Err() 在取消前恒为 nil，所以 if ctx.Err() != nil 或 for ctx.Err() == nil 都是无效轮询，既浪费 CPU，又无法及时响应。

ctx.Done() 是一个永远非 nil 的 channel，但它是否关闭，只能通过接收操作判断——这就是 select 的不可替代性。

• 阻塞型操作（如 time.Sleep、ch 、<code>）必须包裹在 <code>select 中，与 并列
• 非阻塞循环里，每次迭代开头都应有 select { case 结构
• 若只做一次检查（比如启动前校验），可用 if err := ctx.Err(); err != nil，但这不是“监听”，只是快照式判断

WithValue 的 key 为什么不能用 string？

因为 string 作为 key 容易冲突：不同包、不同模块可能无意中用相同字符串做 key，导致值被覆盖或读错，且编译期无法发现。

Go 官方明确建议使用自定义类型（哪怕空 struct）作为 key，保证类型安全和唯一性。

• 错误示范：ctx = context.WithValue(ctx, "user_id", 123) —— 全局字符串 key 极易撞车
• 正确做法：定义私有类型，如 type userIDKey struct{}，再用 ctx = context.WithValue(ctx, userIDKey{}, 123)
• 更稳妥方案：把 key 定义在包内，对外只暴露获取函数，避免外部直接构造 key

树形继承、单向取消、递归查值——这些机制本身很健壮，但一旦 key 冲突，整个上下文携带的数据就不可信了。这点容易被忽略，却直接影响调试和线上稳定性。