context 不实现功能，只安全传递取消信号、超时控制和轻量元数据；所有实用功能源于合理组合 withcancel、withtimeout、withvalue 并严格传递链路。
Context 本身不“实现功能”，它只负责安全、可控地传递三类东西：取消信号、超时控制、轻量元数据。所有“实用功能”都来自你如何组合 context.WithCancel、context.WithTimeout 和 context.WithValue，并严格遵循传递链路。
为什么 ctx.Value(key) 总是返回 nil
根本不是 API 写错了，而是你没真正把新 context 传下去。
-
context.WithValue返回一个全新 context 实例，原变量不变；漏掉赋值或没传参，下游拿到的还是旧 ctx - HTTP 中间件里常见错误：
r.Context()是只读副本，必须显式调用r = r.WithContext(newCtx)才能让后续 handler 看到新值 - key 类型必须是未导出私有类型（如
type userIDKey struct{}），用字符串或 int 做 key 容易被其他包覆盖，静默丢失值 -
context.Value只接受可比较类型；传[]byte、map或指针会 panic，不是编译错误，是运行时报错
context.WithCancel 和 context.WithTimeout 别混着用
它们创建的 context 类型不同，取消行为和资源管理逻辑也不同。
-
context.WithCancel(parent)：纯手动控制，cancel 函数调用一次后再次调用会 panic —— 除非你自己加了防护（比如用 sync.Once 包一层） -
context.WithTimeout(parent, d)：本质是WithDeadline(parent, time.Now().Add(d))，超时后自动触发 cancel，且 cancel 函数幂等，可重复调用 - 测试时最常漏的是
defer cancel()：WithTimeout 创建的 timerCtx 内部持有*time.Timer，不 defer 就泄漏 goroutine 和 timer 资源 - 如果业务既要手动取消又要超时兜底，应该用
WithTimeout，然后在需要时主动调cancel()，而不是套两层 cancel
监听 ctx.Done() 时必须检查 ctx.Err()
只写 case 是危险的，你完全不知道退出原因。
- 无法区分是用户主动中断（
errors.Is(ctx.Err(), context.Canceled)）还是超时（errors.Is(ctx.Err(), context.DeadlineExceeded)） - 清理逻辑可能不同：超时要记监控指标，取消可能要发告警；忽略
ctx.Err()就等于放弃分类处理能力 - Done channel 关闭后，
ctx.Err()才稳定返回非 nil 值；在 select 外直接调ctx.Err()可能拿到 nil（尚未触发） - 正确姿势是在
case 分支内立刻执行 <code>err := ctx.Err()，再做判断
真正容易被忽略的点是：context 的 value 和取消信号走的是两条独立路径。你可以用 WithValue 传用户 ID，但这个值不会影响取消时机；也可以用 WithTimeout 控制整体耗时，但它不自动帮你注入任何业务数据。把这两条线拧在一起靠的是人，不是框架——每次函数调用都要显式传 ctx，每个中间件都要记得 WithContext，少一步，整条链就断了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
