context.Err() 返回错误是状态反馈而非异常，cancel() 关闭 Done 通道后 Err() 幂等返回 context.Canceled 等终态错误，需及时检查而非忽略或延迟响应。
调用 cancel 函数后，context.Err() 返回错误，不是因为“出错了”，而是明确告诉你：这个 context 已被主动取消或超时结束。它本质是状态反馈，不是异常信号。
Done 通道关闭触发 Err 可读
cancel() 的核心动作是关闭 ctx.Done() 返回的 channel。Go 规定：一旦 channel 关闭，ctx.Err() 就不再返回 nil，而是立即返回具体错误值：
-
手动 cancel → 返回
context.Canceled -
超时或 deadline 到期 → 返回
context.DeadlineExceeded - Go 1.21+ 使用 WithXXXCause → 返回你自定义的错误（含原因描述）
Err 是幂等且只读的状态快照
ctx.Err() 每次调用都返回相同结果，不会改变 context 状态，也不阻塞。它只是检查内部 err 字段是否已被设置：
- 未取消时：err 字段为 nil，Err() 返回 nil
- cancel() 执行后：err 字段被设为对应错误，后续所有 Err() 调用都稳定返回该值
- 即使多次调用 cancel()，err 字段也不会覆盖或重置（首次设置即终态）
常见误用：忽略 Err 或延迟检查
很多问题其实源于没在关键路径上及时响应 Err()：
- 数据库操作（如 GORM）若未监听 Done()，就无法感知取消，但调用结束后仍会看到 ctx.Err() 非 nil —— 这说明取消发生在执行中或之前，只是没被及时处理
- 协程里只检查一次
- 把 ctx.Err() 当成 panic 错误去 recover，其实它不该 panic，而应作为控制流分支依据
调试建议：结合 Err 和调用栈看源头
单纯看 ctx.Err() 只知道“被谁取消”，但不知道“谁发起的取消”。要定位根因：
- 检查 cancel() 是谁调用的（比如 HTTP handler 超时、客户端断连、上级服务主动 cancel）
- Go 1.21+ 推荐用 WithDeadlineCause/WithTimeoutCause，让 Err() 带业务线索，例如
Err() == errors.New("order timeout: payment service unresponsive") - 日志中统一打印
ctx.Err().Error()+ 当前函数名，比只打 "context canceled" 有用得多
基本上就这些。Err 不是 bug，是 context 设计里最诚实的状态出口。
