Go error 接口比较相同文本为什么仍然不相等

Go 里两个错误的 Error() 文本完全相同，直接用 == 比较仍然可能得到 false。原因是 error 是接口：比较时看的是接口中的动态类型和值，不是把返回文本当作唯一编号。处理可识别的错误原因，应复用同一个 sentinel 错误并使用 errors.Is；需要读取自定义错误字段时，再用 errors.As。

相同文本为什么不是同一个 error

error 接口里至少要区分两层信息：动态类型和动态值。Error() 只是把错误格式化成字符串，用于日志和提示；它不是接口相等比较的依据。下面的两个值看起来一样，但分别由两次 errors.New 创建：

package main

import (
    "errors"
    "fmt"
)

func main() {
    first := errors.New("配置不存在")
    second := errors.New("配置不存在")

    // 这里比较的是两个 error 值，不是比较 Error() 返回的文字。
    fmt.Println(first == second)                 // false
    fmt.Println(first.Error() == second.Error()) // true，仅说明文本相同
}

接口相等要求动态类型相同且动态值相等。标准库并没有承诺“错误文本相同就复用同一个值”，所以重新创建的错误不能拿来和旧错误做身份比较。把 err.Error() 与字面量比较虽然能得到预期结果，却会把易变的展示文案变成隐含协议，后续加上下文、翻译文案或调整标点都可能让分支失效。

先声明 sentinel，再比较同一个错误

如果调用方确实需要知道“配置不存在”这一原因，就在包级别声明一个稳定的 sentinel。生产代码返回这个变量本身，调用方才有一个明确的比较目标：

package config

import "errors"

// ErrNotFound 是对外可识别的原因；它的身份属于包的错误契约。
var ErrNotFound = errors.New("配置不存在")

func Load(name string) error {
    if name == "" {
        // 返回预先声明的同一个值，调用方可以用 == 或 errors.Is 判断。
        return ErrNotFound
    }
    return nil
}

调用方可以写 err == config.ErrNotFound，但更推荐直接使用 errors.Is。后者兼容后续增加上下文的写法，调用方不用随着返回形式变化而改分支。

用 errors.Is 判断错误原因

需要在错误中补充文件名、请求参数或业务动作时，用 %w 包装原错误。%w 会保留可检查的错误链，%v 只负责格式化文字，不能让 errors.Is 穿透到原错误：

package main

import (
    "errors"
    "fmt"
)

var ErrNotFound = errors.New("配置不存在")

func load() error {
    // %w 保留 ErrNotFound；日志仍然能看到动作上下文。
    return fmt.Errorf("读取 app.yaml 失败: %w", ErrNotFound)
}

func main() {
    err := load()
    if errors.Is(err, ErrNotFound) {
        // 业务分支依据原因，而不是依赖易变的完整错误文本。
        fmt.Println("进入默认配置流程")
    }
}

errors.Is 会先检查当前错误，再沿着 Unwrap 关系查找目标；标准库文档也说明，错误可能通过 Unwrap() error 或 Unwrap() []error 形成链或树。因此它适合判断“是否属于某个已约定原因”。如果底层错误不应成为包的公开契约，就不要随意用 %w 暴露它，可以用 %v 只保留文字上下文。

需要错误字段时改用 errors.As

有些分支不是判断一个固定原因，而是要读取路径、状态码或字段值。这时应该定义具体错误类型，并用 errors.As 从包装链中提取它：

package main

import (
    "errors"
    "fmt"
)

type ParseError struct {
    Line int
    Msg  string
}

func (e *ParseError) Error() string {
    return fmt.Sprintf("第 %d 行：%s", e.Line, e.Msg)
}

func main() {
    err := fmt.Errorf("读取配置失败: %w", &ParseError{Line: 8, Msg: "缺少冒号"})

    var parseErr *ParseError
    // As 按错误类型查找，并把匹配到的值写入 parseErr。
    if errors.As(err, &parseErr) {
        fmt.Println(parseErr.Line, parseErr.Msg)
    }
}

可以把选择规则记成一句话：知道“是不是这个原因”，用 errors.Is；知道“是不是这种错误并要读字段”，用 errors.As；只想记录给人看的信息，就直接输出错误，不拿文本驱动业务流程。

生产代码的错误比较清单

相关问题

为什么同一个错误变量用 == 有时能比较成功？

因为两边引用的是同一个 sentinel，接口中的动态类型和值满足相等条件。为了兼容包装和未来实现变化，调用方仍建议使用 errors.Is。

把错误转换成字符串再比较可以吗？

只能用于非常局部的展示测试，不能作为稳定业务判断。错误文本可能增加上下文或调整措辞，程序需要的是原因或类型。

errors.Is 能判断自定义错误吗？

可以。自定义类型可以实现 Is(error) bool 定义匹配规则；如果目标是读取自定义类型的字段，则应使用 errors.As。

最终检查错误分支时，先问“我要判断原因、提取类型，还是只记日志”。把这个问题回答清楚，通常就不会再被“文本相同但 error 不相等”困住。