withcancel仅对监听ctx.done()的逻辑生效，须配合支持context的api使用；withvalue只存请求级不可变元数据，键需自定义类型，避免传可变对象或依赖实例。
WithCancel 什么时候该用，什么时候不该用
取消操作不是万能的“兜底开关”，它只对主动监听 ctx.Done() 的逻辑生效。如果你的函数没读这个 channel，调用 cancel() 就像按了个没接线的开关——看起来按了，其实什么都没断。
常见错误现象：http.Get 调用后立刻调 cancel()，但请求还在发；数据库查询没传 ctx 或没在驱动里用 ctx，cancel 后 goroutine 照样卡在 rows.Next()。
- 必须配合支持 context 的 API 使用：比如
http.NewRequestWithContext、db.QueryContext、time.AfterFunc替换time.After - 不要用
WithCancel替代超时控制——该用WithTimeout就别手写 timer + cancel - 父子 cancel 关系要清晰：子 ctx cancel 不影响父 ctx，但父 cancel 会级联关闭所有子 ctx（包括
WithValue包裹的）
WithValue 存东西的边界在哪
WithValue 不是 Go 版的全局变量容器，它的设计意图非常窄：只存**请求生命周期内、跨多层函数传递的、不可变的元数据**，比如用户 ID、请求追踪 ID、租户标识。
常见错误现象：存一个 *sql.DB 或 sync.Mutex 进去，结果下游函数取出来直接用，导致并发 panic 或连接泄漏；或者存一个 struct 指针，上游改了字段，下游读到脏数据。
立即学习“go语言免费学习笔记（深入）”；
- 值必须是线程安全的：推荐用基本类型、字符串、不可变 struct，避免指针或可变对象
- 键不能用裸字符串——用自定义类型做 key，防止不同包之间 key 冲突：
type ctxKey string; const userCtxKey ctxKey = "user" - 不要用它传配置、工具函数、依赖实例——那些该通过参数、依赖注入或闭包传
WithCancel 和 WithValue 组合使用的典型陷阱
组合本身没问题，但顺序和生命周期管理一错就难排查。最常踩的坑是：先 WithValue，再 WithCancel，然后只保留 value ctx，却忘了 cancel 函数还在老的 parent ctx 上——结果 cancel 调了，value ctx 却没关。
使用场景：HTTP handler 中解析 auth token（存入 value），同时启动一个后台 fetch（需要 cancel 控制）。
- 顺序建议：先
WithCancel，再WithValue，确保 value ctx 是 cancel ctx 的子节点 - cancel 函数必须在合适时机调用：比如 handler 返回前、goroutine 结束时；漏调会导致 goroutine 泄漏
- 不要把
WithValue的 ctx 传给另一个独立的WithCancel链——容易形成孤儿 ctx，无法被统一 cancel
Context.Value 的性能与调试成本
查 ctx.Value 是 O(n) 链表遍历，n 是嵌套层数。10 层以内基本无感，但若在 hot path（比如 HTTP middleware 内循环取值）反复调用，会有可观开销。更麻烦的是调试：值在哪一层塞进去的？被谁覆盖过？运行时完全不报错，只默默返回 nil。
错误信息示例：panic: assignment to entry in nil map —— 很可能是因为你取 ctx.Value 返回了 nil，又直接当 map 用了。
- 上线前用
ctx.Value前先判空：v := ctx.Value(key); if v == nil { /* 处理缺失 */ } - 避免在循环里反复取同一个 key，提取到局部变量
- 测试时可临时加日志：在
WithValue处打点，记录 key/value/调用栈，出问题时比盲猜快得多
事情说清了就结束。Context 的组合能力越强，越容易让人忽略它只是个信号+传参的协约，不是魔法容器。真正难的从来不是怎么写，而是想清楚哪些该由它管，哪些不该。
