GolangSentinelError判断方法详解

在 Go 错误处理中，哨兵错误（sentinel error）是标识特定失败场景的轻量级契约，而 `errors.Is` 是其真正可靠的判断工具——它通过递归遍历错误链精准识别被 `fmt.Errorf("%w")` 包装的原始哨兵，彻底规避 `==` 比较在包装后失效的风险；正确定义需用 `var ErrX = errors.New(...)` 导出变量，禁用 `const` 或字符串匹配；当错误需携带上下文数据、语义分化或深度包装时，应升级为自定义错误类型配合 `errors.As`；归根结底，哨兵错误的价值不在于定义，而在于整个错误传播链中始终可追溯、可识别，`errors.Is` 正是维系这一契约的底层锚点。

为什么 errors.Is 比 == 更安全地判断哨兵错误

因为 Go 的 error 是接口类型，直接用 == 比较两个 error 值，实际比较的是底层结构体指针或具体值的相等性，而很多错误包装（比如 fmt.Errorf("wrap: %w", err)）会让原始哨兵 error 被嵌套，此时 == 就失效了。

• errors.Is(err, ErrNotFound) 会递归检查 err 是否是 ErrNotFound，或是否通过 %w 包装过它
• 直接写 err == ErrNotFound 在没包装时能工作，但只要上游用了 fmt.Errorf("failed: %w", ErrNotFound)，这个判断就永远为 false
• 如果你的函数返回的是 fmt.Errorf("db: %w", sql.ErrNoRows)，而你又想统一识别成“未找到”，那就必须用 errors.Is(err, sql.ErrNoRows)，而不是自己再造一个 ErrNotFound

定义哨兵 error 的正确姿势：用 var + errors.New，别用 const 或字符串比较

哨兵 error 必须是变量（var），不能是常量（const），否则 errors.Is 无法识别其地址唯一性；也不能用字符串内容比对（比如 err.Error() == "not found"），那既脆弱又破坏错误语义。

• ✅ 正确：var ErrNotFound = errors.New("record not found")
• ❌ 错误：const ErrNotFound = "record not found"（类型不对，errors.Is 完全不认）
• ❌ 危险：strings.Contains(err.Error(), "not found")（拼写、翻译、日志附加文本都会让判断崩掉）
• 注意：包内定义的哨兵 error 应该导出（首字母大写），但不要暴露实现细节——比如别写 var ErrNotFound = &myError{"not found"}，除非你明确实现了 Unwrap() 和自定义比较逻辑

什么时候不该用哨兵 error：包装过多、领域语义模糊、需要携带数据

哨兵 error 只适合表达“一类固定、无歧义、无需额外上下文”的失败场景。一旦你需要告诉调用方“哪个 ID 没找到”或“第几行解析失败”，它就撑不住了。

• 如果错误要附带字段（如 UserID int、Line int），应该用自定义 error 类型 + 实现 Unwrap() 和 Error()，再配合 errors.Is / errors.As
• 如果业务里“找不到”分好几种含义（缓存未命中、DB 空结果、API 返回 404），硬塞同一个 ErrNotFound 会导致调用方无法区分处理逻辑
• 过度包装也会稀释哨兵意义：比如每层都 fmt.Errorf("service: %w", repo.ErrNotFound)，最后上层仍得靠 errors.Is(err, repo.ErrNotFound)，但包路径变深、维护成本上升——这时考虑把哨兵 error 提到共享包，或改用错误分类（如返回 errorKind 枚举）

errors.As 和 errors.Is 别混用：前者抓具体类型，后者判哨兵身份

这是最常混淆的一点：errors.Is 用于哨兵 error（值相等性判断），errors.As 用于提取包装里的具体 error 类型实例（类型断言）。它们解决的是不同层级的问题。

• 用 errors.Is(err, io.EOF) 判断是不是 EOF —— 这是标准哨兵，Go 官方已定义好
• 用 errors.As(err, &e) 把 err 里嵌套的 *MyAppError 实例拿出来，以便访问它的 e.Code 或 e.ReqID
• 常见错误：写成 errors.Is(err, &MyAppError{}) —— errors.Is 不接受地址字面量，只接受已定义的哨兵变量；而 &MyAppError{} 每次都是新地址，永远不等于任何已有变量
• 示例：

  var e *MyAppError
  if errors.As(err, &e) {
      log.Printf("app error code: %d", e.Code)
  }

哨兵 error 看似简单，真正难的是在错误传播链中保持它的可识别性——不是定义那一刻，而是每次被包装、重写、跨服务传递之后，还能被准确捕获。这点上，errors.Is 是你的锚点，但前提是上游没人绕过它直接造字符串 error。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。