以下关键点需要重点掌握： 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() 返回 DeadlineExceeded，但底层的 time.Timer 及其 goroutine 并不会自动停止。它们仍然存活并占用着资源，直到你显式清理。
- 不调用
cancel()→ 导致定时器泄漏，goroutine 持续占用内存和调度资源 - 只在超时后调用 → 依然为时已晚，泄漏已经发生
- 正确做法：始终用两个变量接收，并在作用域末尾添加
defer cancel()，无论任务提前完成还是出错都必须执行
HTTP 请求中 context 不生效的常见错误写法
最常见的误区是：你修改了请求对象的 context，但 http.Client.Do 根本没有接收到这个信号。
http.Client 自身的 Timeout 字段无法覆盖 DNS 解析、TLS 握手、连接池等待等环节；只有通过传入 context 才能实现全链路统一控制。
- 错误示范：
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）必须包裹在select中，与<-ctx.Done()并列监听 - 非阻塞循环里，每次迭代开头都应包含
select { case <-ctx.Done(): ... default: ... }结构 - 若只做一次检查（比如启动前校验），可用
if err := ctx.Err(); err != nil，但这不是“监听”，只是快照式判断
WithValue 的 key 为什么不能用 string？
因为 string 作为 key 极易冲突。不同包、不同模块很可能无意间使用了相同的字符串作为 key，导致值被覆盖或读取错误，而且编译期根本无法发现。
Go 官方明确建议使用自定义类型（哪怕是一个空结构体）作为 key，这样才能保证类型安全和唯一性。
- 错误示例：
ctx = context.WithValue(ctx, "user_id", 123)—— 全局字符串 key 极易撞车 - 正确做法：定义私有类型，如
type userIDKey struct{}，再用ctx = context.WithValue(ctx, userIDKey{}, 123) - 更稳妥方案：把 key 定义在包内，对外只暴露获取函数，避免外部直接构造 key
树形继承、单向取消、递归查值——这些机制本身很健壮，但一旦 key 冲突，整个上下文携带的数据就不可信了。这一点容易被忽略，却直接影响调试和线上稳定性。
