17370845950

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 设计里最诚实的状态出口。