必须调用cancel()，因其负责停止time.timer、关闭done通道、清理子节点引用；不调用会导致timer驻留、goroutine泄漏及内存无法回收。
context.WithTimeout 为什么必须配对使用 cancel() 函数
不调用 cancel() 会导致底层 time.Timer 和 goroutine 持续运行，无法被 GC 回收，最终引发资源泄漏。
-
context.WithTimeout内部启动一个定时器，超时后自动调用cancel()，但这不意味着你可以忽略显式调用 - 即使超时已触发，
time.Timer仍持有引用；不调用cancel()，该 timer 就不会停止 - 常见错误是只接收
ctx，丢弃cancel：ctx, _ := context.WithTimeout(...) - 正确写法始终是：
ctx, cancel := context.WithTimeout(...)，并在作用域末尾defer cancel() - 提前 return 的分支也需确保
cancel()被调用，否则 timer 泄漏
HTTP 请求中 context 超时为何经常“没生效”
根本原因不是 context.WithTimeout 失效，而是你没把 ctx 传到底层可取消的环节，或底层系统调用根本不响应 cancel 信号。
-
http.Client.Timeout和context控制点不同：前者只管整个请求生命周期（DNS+连接+读写），后者需靠http.NewRequestWithContext(ctx, ...)显式注入 - 错误写法：
req = req.WithContext(ctx)但调用client.Do(req)—— 实际上req.Context()已更新，但某些旧版 client 或自定义 transport 可能忽略它 - 更稳妥的做法是：
client.Do(req.WithContext(ctx))，确保上下文在 Do 调用前就绑定 - DNS 解析、TCP 连接建立、TLS 握手等阶段在 Go 1.19 前默认不响应
ctx.Done()；需配合http.Transport.DialContext等字段手动接入 - 如果只设了
client.Timeout，它内部会新建子 context，可能覆盖你传入的 deadline
监听 ctx.Done() 为什么不能用 if 或 for 循环
ctx.Done() 是 channel，不是布尔状态；直接 if ctx.Done() != nil 或 for ctx.Err() == nil 完全无效，且极易导致逻辑卡死或错过取消信号。
-
ctx.Done()永远是非 nil 的有效 channel，未关闭时读取会阻塞；判断是否关闭只能靠select -
ctx.Err()在取消前恒为nil，所以for ctx.Err() == nil等价于无限循环 - 正确监听方式只有：
select { case ，且应嵌入到所有等待逻辑中（如轮询、I/O 等待） - 在 long-running 协程里，不能只在开头 check 一次，必须在每次循环迭代或关键等待点插入
select - 若
select中只有case 和 <code>default，要注意default可能导致忙等；必要时加time.Sleep或改用带超时的select
WithValue 的 key 为什么不能用 string 类型
用 string 作 context.WithValue 的 key 极易引发跨包冲突，导致值被意外覆盖或读错，属于隐蔽性极强的 bug 来源。
-
context.WithValue要求 key 可比较，string满足语法要求，但语义上不具备唯一性 - 不同模块都用
"user_id"作 key，实际存取的是同一 slot，互相污染 - 正确做法是定义私有类型：
type userIDKey struct{}，再用userIDKey{}作 key - 哪怕只在一个包内用，也建议用非导出类型 + 变量封装，避免被外部误用
-
context.WithValue仅用于传递请求范围的元数据（如 traceID、auth token），绝不该用来传业务参数或大对象
http.Client 内部新建的子 context，可能截断你原本的取消链。这些细节不调试很难暴露，一上线就变成 goroutine 泄漏或超时失灵。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
