Go中判断Context取消错误的方法

在 Go 语言中，正确判断 Context 取消错误是保障程序健壮性与资源安全的关键——必须使用 `err == context.Canceled` 或 `err == context.DeadlineExceeded` 进行精确值比较，而非字符串匹配或简单非空判断；同时，仅调用 `ctx.Err()` 是静态快照，真正响应取消需通过 `select` 监听 `ctx.Done()` 通道，尤其在 HTTP handler、子 goroutine 和 I/O 操作中，遗漏这一机制极易导致连接不释放、goroutine 泄漏和逻辑滞后；而 `context.WithValue` 与取消无关，滥用它模拟取消逻辑更是典型反模式——归根结底，写每一段并发代码时，都要本能地自问：这个 ctx，真的能及时感知并响应取消吗？

ctx.Err() 返回 context.Canceled 还是 context.DeadlineExceeded？

判断 Context 是否取消，不能只看 err != nil，必须显式比对错误值。Go 标准库里 context.Canceled 和 context.DeadlineExceeded 是预定义的导出变量，不是字符串或临时错误实例，所以要用 == 判断，不能用 errors.Is()（虽然它也支持，但没必要绕弯）。

• ctx.Err() 在 Context 被取消时返回 context.Canceled；超时则返回 context.DeadlineExceeded
• 如果 Context 没被取消或没设 deadline，ctx.Err() 返回 nil
• 别用 err.Error() == "context canceled" —— 字符串匹配脆弱，且在 Go 1.22+ 中错误消息可能本地化
• 示例：

  if err := ctx.Err(); err != nil {
      if err == context.Canceled {
          // 处理主动取消
      } else if err == context.DeadlineExceeded {
          // 处理超时
      }
  }

为什么 select 里要同时监听 ctx.Done() 和业务 channel？

单纯调用 ctx.Err() 是“快照式”检查，无法感知后续取消；而 .Done() 是一个只读 channel，一旦 Context 取消就永久关闭，适合和业务 channel 一起用 select 做非阻塞响应。

• 不监听 ctx.Done()，你的 goroutine 可能永远卡在 read 或 http.Do 上，哪怕 Context 已取消
• 监听 ctx.Done() 后，select 会立即跳出，避免资源泄漏和逻辑滞后
• 注意：ctx.Done() 关闭后，ctx.Err() 才会返回非 nil 值；两者是配套机制，不是替代关系
• 常见错误：在 select 外部先调 ctx.Err() 判断，再进 select —— 这中间存在竞态窗口，可能错过取消信号

HTTP handler 中误用 ctx.Err() 导致连接不释放

在 http.Handler 里，r.Context() 是 request-scoped 的，它的取消意味着客户端断开或超时。但如果你在 handler 内部启动了子 goroutine 并直接传入该 ctx，又没做 cancel 链传递，子 goroutine 可能持续运行，还持有 response writer 引用，导致连接无法释放。

• 不要在子 goroutine 中直接用 r.Context()，应使用 context.WithCancel(r.Context()) 或 context.WithTimeout() 显式派生
• 尤其注意数据库查询、日志上报、异步通知等场景 —— 它们常忽略父 ctx 的生命周期
• 典型现象：net/http: abort Handler 日志出现后，goroutine 仍在跑，pprof 显示堆积
• 验证方法：在 handler 结尾加 log.Println("handler exit, ctx.Err():", r.Context().Err())，若输出 nil，说明你没正确监听取消

context.WithValue 和 ctx.Err() 没有关系，但常被混淆

context.WithValue 只是往 Context 树里塞键值对，不影响取消行为；它的存在不会改变 ctx.Err() 的返回值，也不会触发取消。很多人以为“存了东西进去，就得自己管生命周期”，其实完全不必 —— 取消信号仍由最上游的 WithCancel 或 WithTimeout 控制。

• ctx.Err() 的行为只取决于 Context 的取消源头，和有没有 WithValue 无关
• 滥用 WithValue 传取消相关标志（比如 "should_cancel"）是反模式，破坏了 Context 的原生传播机制
• 真正需要扩展取消逻辑时，应该用 context.WithCancel 显式控制，而不是靠 value “模拟”
• 性能提示：频繁调用 WithValue 会增加 Context 树深度，虽不影响 Err()，但可能拖慢 Value() 查找

事情说清了就结束。真正难的不是记住 ctx.Err() 怎么用，而是每次写 goroutine、起子任务、发 HTTP 请求时，都下意识问一句：这个 ctx 能及时感知取消吗？

好了，本文到此结束，带大家了解了《Go中判断Context取消错误的方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！