errors.Is 与直接比较为何结果不同，错误链如何遍历

Go 里把错误继续向上返回时，通常会用 fmt.Errorf("load config: %w", err) 增加上下文。此时再写 err == ErrNotFound，比较的是最外层的包装错误，结果可能是 false；errors.Is(err, ErrNotFound) 则会沿错误链寻找匹配值。简单说：判断错误语义用 errors.Is，读取具体错误类型用 errors.As，不要拿错误文本做分支条件。

直接比较和 errors.Is 检查的对象不是一层

先看一个最小场景。ErrNotFound 是调用方关心的稳定信号，外层错误只负责补充“加载哪个配置”的上下文：

var ErrNotFound = errors.New("config not found")

func loadConfig() error {
	// %w 保留底层错误，让上层仍能按 ErrNotFound 分支处理。
	return fmt.Errorf("load service.yaml: %w", ErrNotFound)
}

func handle() {
	err := loadConfig()
	// == 只比较当前返回值，包装后通常不会等于哨兵错误。
	fmt.Println(err == ErrNotFound) // false
	// errors.Is 会继续检查 Unwrap 链。
	fmt.Println(errors.Is(err, ErrNotFound)) // true
}

即使错误消息完全一样，重新调用 errors.New 得到的两个错误值也不是同一个哨兵。生产代码应在包级定义可复用的错误值，返回时用 %w 包装，而不是依赖字符串相等。

错误链会从外层向内层展开

错误实现了 Unwrap() error，就可以把内部错误暴露给标准库的检查函数。errors.Is 先看当前节点，再沿包装关系向下检查；当错误包含多个子错误时，标准库文档把它视为一棵树，并按深度优先方式访问。

这意味着中间层可以不断补充上下文，调用方仍只依赖最初定义的语义：

func readConfig() error {
	// 内层保留根因，外层消息只补充业务位置。
	return fmt.Errorf("read config: %w", ErrNotFound)
}

func request() error {
	err := readConfig()
	// 再包一层仍不会破坏 Is 的匹配能力。
	return fmt.Errorf("prepare request: %w", err)
}

func isMissing(err error) bool {
	// target 应是可比较的稳定错误值。
	return errors.Is(err, ErrNotFound)
}

errors.Unwrap 只取下一层，适合确实需要手动查看结构的场景；单纯判断“是否属于某类错误”，优先使用 errors.Is，避免自己漏掉多层包装或多错误分支。

值判断、类型提取和自定义 Is 不要混用

自定义 Is 适合表达有限的兼容关系，例如某个结构化错误可以被当作 ErrPermission。它不应该把任意字段都忽略，也不应该在内部递归调用 errors.Is，否则会让匹配范围难以推断。

生产代码的错误判断清单

1. 返回上下文时使用 %w，只有刻意隐藏根因时才使用 %v。
2. 对包级哨兵错误使用 errors.Is，不要比较错误消息。
3. 需要访问结构化字段时使用 errors.As，并先判断成功再读取字段。
4. 使用 errors.Join 后，把结果看作错误树；不要假定只有一条线性链。

最后检查一个常见误区：errors.Is(err, target) 不是“错误字符串包含 target”，也不是对所有结构体做深度相等。它依赖错误值相等或错误类型提供的 Is 规则，匹配到后即可让上层稳定决策。

相关问题

errors.Is 能替代所有的 == 比较吗？

不能。它适合错误语义判断；如果代码明确只关心同一个可比较值且没有包装语义，直接比较仍然有效。

为什么 errors.As 不用来判断哨兵错误？

errors.As 的目标是提取匹配类型并读取字段；固定错误值的存在性判断应使用 errors.Is。

什么时候不该使用 %w？

当你不希望调用方依赖内部错误身份，或根因可能暴露不应公开的实现细节时，可以只格式化消息而不建立可检查的包装关系。