context.withcancel 必须配 defer cancel()，否则导致 goroutine 泄漏；withtimeout/withdeadline 受系统时钟和调度影响，非硬实时；withvalue 需用私有类型作 key 避免冲突；多级 context 的 done 关闭不保证顺序。
context.WithCancel 必须配 defer cancel()，否则 goroutine 泄漏
不调用 cancel() 是最常见、最隐蔽的泄漏源。Go 的 context.WithCancel 返回的 cancel 函数不是“可选清理”，而是唯一释放内部资源（如 children map 和 mutex）的出口。
- 漏掉
defer cancel()会导致父 context 持有对子 canceler 的引用，子 goroutine 无法被 GC，且后续所有派生 context 的Done()通道永不关闭 - 即使只用一次，也要写
defer cancel()；嵌套调用时，每个WithCancel都要配自己的defer - 注意：
cancel()可安全重复调用，但第二次起无副作用 —— 所以放在defer里不会出错
WithTimeout 和 WithDeadline 的超时精度与系统时钟依赖
context.WithTimeout 底层靠 *time.Timer 实现，实际触发时间受 Go runtime 调度和系统时钟精度影响，不能当作硬实时控制。
-
WithTimeout(ctx, 10*time.Millisecond)可能在 12–15ms 后才真正关闭Done()，尤其在高负载或 GC STW 期间 -
WithDeadline同样依赖系统时钟，若机器时间被 NTP 向后跳变（如校准），可能提前触发取消；向前跳变则可能延迟 - 对延迟敏感场景（如金融交易），应额外加一层业务层超时判断，不要仅依赖
ctx.Done()
WithValue 传参必须用自定义 key 类型，避免 key 冲突
context.WithValue 的 key 参数是 any 类型，但直接用字符串或整数作 key 极易在不同包间冲突，导致值被意外覆盖或读不到。
- 正确做法：定义未导出的私有类型，例如
type requestIDKey struct{}，再用ctx = context.WithValue(ctx, requestIDKey{}, "abc123") - 绝对不要用
context.WithValue(ctx, "user_id", 123)—— 第二个包也用"user_id"就会覆盖前一个 -
Value()返回nil不代表没设值，可能是设了nil，所以判空要用v := ctx.Value(key); if v != nil { ... }，而非if ctx.Value(key) != nil（后者可能 panic）
多级派生 context 时，Done() 通道关闭是级联但非原子的
当父 context 被 cancel，所有子 context 的 Done() 会陆续关闭，但**没有顺序保证，也不保证同时发生** —— 这在竞态调试中常被误认为“传播失败”。
- 子 context 的
cancel调用是加锁执行的，但锁粒度在每个 cancelCtx 实例上，不是全局锁 - 如果 A → B → C → D 四层，A 被 cancel 后，B 关闭 Done 可能比 D 快 10μs，但 D 的
Err()仍会返回context canceled，因为它的父 C 已标记 err - 因此，永远不要在 goroutine 中轮询
ctx.Err() == nil来判断是否“还没取消”，而应始终监听
实际并发控制中最容易被忽略的，是 cancel 函数的生命周期管理 —— 它不是上下文的一部分，而是独立对象，一旦丢失引用就再无回收路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
