ctx.Err() 返回 nil 但实际已取消？检查取消链是否被意外截断
Go 的 context.Context 取消信号是单向、不可逆、逐层向下的。如果子 Context 没有正确继承父级的取消逻辑，ctx.Err() 就可能长期返回 nil，哪怕上游早已调用 cancel()。
常见错误是手动创建新 Context（比如用 context.WithValue）却不基于已取消的父 context；或者在 goroutine 中误用 context.Background() 替代传入的 ctx。
- 总是用
context.WithCancel/context.WithTimeout/context.WithDeadline基于上游ctx创建子 context，而不是context.Background()或context.TODO() - 避免在中间层“重置” context：比如把
ctx传进函数后，又用context.WithValue(ctx, key, val)生成新 context，这本身没问题；但如果上游已取消，这个新 context 仍会正确反映ctx.Err()—— 关键是别丢掉原始ctx引用 - 调试时可打印
fmt.Printf("err: %v, ctx: %p", ctx.Err(), ctx)，对比父子 context 地址和 err 值，确认是否同一取消树
为什么 ctx.Err() == context.Canceled 却没触发预期清理？检查 defer 和 select 的执行时机
ctx.Err() 变为非 nil 只代表“取消已发生”，不代表“所有监听者都收到了”。尤其在 goroutine 中，若清理逻辑写在 defer 里，而 goroutine 已因其他原因提前退出（比如 panic、return），defer 就不会运行。
更隐蔽的问题是：select 语句中同时监听 ctx.Done() 和其它 channel，但未处理 ctx.Err() 的具体值，导致 context.DeadlineExceeded 被当成普通取消忽略。
立即学习“go语言免费学习笔记（深入）”；
- 永远在
select后立刻检查ctx.Err()，不要只依赖的接收动作 - 清理逻辑尽量不依赖
defer，尤其涉及资源释放（如关闭文件、连接）时，应显式写在case 分支里 - 区分错误类型：
errors.Is(ctx.Err(), context.Canceled)和errors.Is(ctx.Err(), context.DeadlineExceeded)行为可能不同，比如重试策略要区别对待
子 context 的 Done() channel 比父 context 更早关闭？确认是否重复调用 cancel()
每个由 context.WithCancel 等生成的 cancel 函数只能安全调用一次。重复调用会导致子 Done() channel 提前关闭，且 ctx.Err() 可能返回 context.Canceled，即使父 context 还没取消 —— 因为 cancel 函数内部会直接 close 对应的 channel。
这种问题多出现在封装层：比如一个函数接收 ctx 并调用 context.WithTimeout(ctx, ...)，然后在多个出口处都调用了生成的 cancel()。
- 用
sync.Once包裹 cancel 调用（不推荐，掩盖设计问题） - 更合理的是：确保 cancel 只在明确的生命周期终点调用一次，比如在函数 return 前、或 error 处理分支末尾
- 临时调试可在 cancel 前加日志：
log.Printf("cancelling ctx %p", ctx)，快速定位重复调用点
HTTP handler 中 ctx.Err() 总是 nil？注意 net/http 对 context 的注入时机
http.Request.Context() 返回的 context 是由 net/http 在请求开始时注入的，其取消由服务器控制（如客户端断开、超时）。但如果你在 handler 中启动 goroutine 并传入该 ctx，需注意：goroutine 可能比 handler 执行更久，而 handler 返回后，该 ctx 仍有效，直到底层连接关闭或超时触发。
容易误判的是：handler 内部用 time.AfterFunc 或 go func() 启动异步任务，却没检查 ctx.Err()，结果任务持续运行，占用资源。
- 不要假设 handler 返回 = context 已取消；只要连接还活着，
ctx.Err()就可能仍是nil - 异步任务中必须主动监听
，并在收到后做清理，不能只靠 defer - 若需更激进的超时控制，应在 handler 内部用
context.WithTimeout(r.Context(), ...)生成子 context，并管理其 cancel
最常被忽略的一点：Context 取消不是“广播”，而是“链式通知”。从根 context 到叶子节点，任意一环断开（比如漏传、误覆写、重复 cancel），下游就收不到信号 —— 这时候看 ctx.Err() 永远是 nil，但你其实已经失去控制权了。
