context 是用于主动取消、超时控制和跨 goroutine 传值的协作机制，不管理生命周期；cancel 函数必须显式调用才能触发 Done 通道关闭，defer 中调用易失效；WithTimeout 基于相对时间且 timer 可立即清理，WithDeadline 基于绝对时间、timer 可能短暂残留；WithValue 仅适用于请求元信息（如 trace-id），禁用业务数据；HTTP handler 返回后 req.Context() 即被取消，异步任务需用 errgroup 或 WaitGroup 独立管理。
Go 的 context 不是用来“掌握生命周期管理”的抽象概念，而是用来**主动取消、超时控制和跨 goroutine 传递请求作用域值**的协作机制——它本身不管理生命周期，而是让多个组件能响应同一个取消信号。
为什么 context.WithCancel 返回的 cancel 必须显式调用
这是最常被误解的一点：很多人以为只要创建了 context.WithCancel，父 context 一结束子 context 就自动失效。实际上，子 context 只在收到 Done() 通道关闭信号后才感知取消，而这个信号必须由你调用返回的 cancel 函数才能触发。
-
cancel是一个函数，不是钩子或监听器；不调用它，子 context 永远不会知道该结束 - 常见错误：在 defer 中调用
cancel，但 defer 只在函数返回时执行，若 goroutine 长期运行（比如 HTTP handler 启动后台任务），cancel就永远不会被调用 - 正确做法：在明确的退出路径上（如 HTTP 请求结束、任务完成、错误返回）调用
cancel；如果启动了子 goroutine，需把cancel传进去并在合适时机触发
context.WithTimeout 和 context.WithDeadline 的区别不只是时间表达方式
表面上看，一个传 time.Duration，一个传 time.Time，但它们对 timer 的调度逻辑不同，影响可观测性和调试行为。
-
context.WithTimeout(parent, d)等价于context.WithDeadline(parent, time.Now().Add(d))，但它内部使用time.AfterFunc，一旦 parent 被 cancel，timer 会被立即停止并释放 -
context.WithDeadline则直接基于绝对时间构建 timer，即使 parent 已 cancel，deadline timer 仍可能短暂存活（取决于 runtime 调度），但其Done()通道仍会受 parent 控制——所以行为上一致，只是资源清理时机略有差异 - 性能上无实质差别；选哪个只看语义：如果你知道截止时刻（如“必须在 2024-10-15T14:30:00Z 前完成”），用
WithDeadline；如果只知道最长允许耗时（如“最多等 5 秒”），用WithTimeout
不要把业务数据塞进 context.WithValue，除非它真是请求范围元信息
context.WithValue 很容易被滥用为“隐式参数传递”，但这会破坏函数签名可读性、增加测试难度，并掩盖控制流依赖。
立即学习“go语言免费学习笔记（深入）”；
- 适用场景仅限：用户身份（
user.ID）、请求 ID（request-id）、跟踪链路 ID（trace-id）这类贯穿整个请求生命周期、且所有中间层都需要但又不该出现在每个函数参数列表中的元数据 - 反例：数据库连接、配置对象、日志 logger 实例——这些应该显式传参或通过依赖注入容器管理；塞进 context 会导致单元测试时不得不构造 fake context，也容易引发类型断言失败（
value, ok := ctx.Value(key).(MyType)） - Key 类型必须是 unexported struct 或私有指针，避免第三方包冲突；别用字符串或公共 int 常量作 key
HTTP server 中的 context 生命周期陷阱
net/http 的 Request.Context() 在请求结束时自动 cancel，但它的生命周期和 handler 执行周期并不完全重合——尤其当你启动 goroutine 异步处理时，很容易误判 context 是否还有效。
- handler 返回后，
req.Context()立即被 cancel，但你启动的 goroutine 可能还在跑；此时再读ctx.Err()会立刻得到context.Canceled，但你无法靠它安全地等待异步任务结束 - 解决方案不是“复制 context”，而是用
errgroup.Group或手动 sync.WaitGroup + channel 组合：把异步任务的完成信号和 context 取消信号分开处理 - 切勿在 goroutine 中直接用
req.Context()做 long-poll 或定时轮询——它可能在几毫秒后就失效，导致不可预期的提前退出
真正难的不是记住 API，而是判断「谁该负责取消」「何时调用 cancel」「哪些值值得放进 context」——这需要结合具体调用链设计，而不是背诵文档。
