Go 自定义 Is 方法为什么不能递归调用 Unwrap

给自定义错误实现 Is(error) bool 时，最容易犯的错是把它写成另一个 errors.Is：先调用 Unwrap()，再递归判断底层错误。这样做不是“更完整地查一层”，而是把错误树的遍历职责重复实现了一遍。

正确分工是：Unwrap 暴露当前错误的原因，errors.Is 统一向下遍历，自定义 Is 只回答“当前这个错误值是否可以视为 target”。官方文档还明确要求自定义 Is 只做浅层比较，不要对任一错误调用 Unwrap。

官方文档：https://pkg.go.dev/errors

errors.Is 为什么会自己继续查 Unwrap

Go 的错误包装不是一条只能走一次的字符串链，而是一棵可被检查的错误树。一个错误可以通过 Unwrap() error 连接单个子错误，也可以通过 Unwrap() []error 连接多个子错误。errors.Is(err, target) 先判断 err 本身，再调用匹配节点提供的 Is，最后继续检查子节点。

因此下面的包装器只需要把原因交给标准库：

package main

import (
    "errors"
    "fmt"
)

var ErrQuota = errors.New("quota exceeded")

type quotaError struct {
    operation string
    cause     error
}

func (e *quotaError) Error() string {
    return fmt.Sprintf("%s: %v", e.operation, e.cause)
}

// Unwrap 只暴露当前错误的底层原因，不在这里做匹配判断。
func (e *quotaError) Unwrap() error {
    return e.cause
}

func main() {
    err := "aError{operation: "write report", cause: ErrQuota}
    fmt.Println(errors.Is(err, ErrQuota)) // true：errors.Is 会继续走 Unwrap
}

如果在 Is 里再次递归，外层的 errors.Is 仍会继续遍历同一批子节点，于是同一段链路被重复走过。错误树越深、分支越多，额外工作越明显；更重要的是，匹配规则会从“当前节点是否等价”变成“我顺便替调用者搜索整棵树”。

自定义 Is 只判断当前错误是否等价

自定义 Is 的价值，是让一个业务错误与稳定的哨兵错误建立等价关系。例如，调用方不必知道 quotaError 的字段布局，只关心它是否代表配额不足：

// Is 只比较当前 quotaError 与目标错误的语义，不向下搜索。
func (e *quotaError) Is(target error) bool {
    return target == ErrQuota
}

func save() error {
    // 返回当前包装器，让调用方同时得到上下文和可匹配的语义。
    return "aError{
        operation: "write report",
        cause:     errors.New("storage rejected request"),
    }
}

func check() {
    if err := save(); err != nil && errors.Is(err, ErrQuota) {
        // 这里命中的是 quotaError 的 Is，不是对底层文本做比较。
        fmt.Println("请稍后重试或申请配额")
    }
}

这个例子里的 Is 没有调用 e.Unwrap()。若当前节点返回 false，标准库会按照它自己的树遍历继续处理 cause。若希望基于字段匹配，也应限制在当前值，例如比较错误码或资源类型，而不是把 target 再传给 errors.Is。

递归调用 Unwrap 会带来哪些具体风险

第一是重复遍历。外层 errors.Is 本来会检查当前节点的 Is，随后再走 Unwrap；自定义方法又走一次，导致同一子树可能被访问多次。

第二是语义越界。自定义 Is 可能把一个“当前节点不匹配、底层节点匹配”的结果提前返回，调用者很难判断这个匹配来自哪个层级。对于 Unwrap() []error，手写递归还容易只处理单错误接口，遗漏多分支错误。

第三是循环风险。错误实现一旦错误地把自己或上层包装器作为原因，递归的 Is 会把这个结构再次放大，最终出现无限递归或难以定位的栈增长。修复时先检查 Is 是否调用了 Unwrap、errors.Is 或相同的匹配 helper，再检查 Unwrap 是否只返回真实子错误。

常见问题

Is 方法能不能比较 target 的具体类型

可以，但比较应停留在当前节点。例如先把 target 断言为约定的业务类型，再比较错误码；不要拿断言结果继续调用 errors.Is。

只实现 Unwrap 不实现 Is 可以吗

可以。只要底层原因或哨兵错误在错误树中，外层 errors.Is 就能沿链查找；只有需要自定义等价规则时才增加 Is。

errors.Unwrap 和 errors.Is 的职责一样吗

不一样。errors.Unwrap 只取一层且只处理 Unwrap() error；errors.Is 才负责匹配并继续遍历错误树，也能处理多错误包装。