Golang错误链error wrapping的实现原理_技术教程

Go 1.13 的 errors.Is 和 errors.As 能穿透多层包装，是因为 fmt.Errorf(%w) 等自动为 error 添加 Unwrap() 方法，errors 包递归调用该方法直至匹配或 nil；未实现 Unwrap 的 error（如 errors.New）无法穿透，%v 不触发包装，自定义 error 需显式实现 Unwrap 返回 Cause。

Go 1.13 的 `errors.Is` 和 `errors.As` 为什么能穿透多层包装？

因为 Go 运行时在底层为每个被 fmt.Errorf（带 %w）或显式调用 errors.Wrap（第三方）包装的 error，自动附加一个隐式接口实现：Unwrap() error。只要一个 error 类型实现了这个方法，errors.Is 和 errors.As 就会递归调用它，逐层“剥开”直到找到匹配的底层 error 或返回 nil。

关键点在于：这不是语法糖，而是由编译器和运行时协同保障的约定行为——所有标准库包装函数（如 fmt.Errorf("...", err) 中的 %w）都生成满足该接口的私有结构体。

fmt.Errorf("failed to read: %w", io.EOF) 生成的对象内部持有一个 io.EOF 字段，并实现了 Unwrap() error { return io.EOF }
如果某层 error 返回 nil 表示已到底层，遍历终止
若 error 类型未实现 Unwrap（比如直接 errors.New("xxx")），则无法被穿透

`%w` 和 `%v` 在 `fmt.Errorf` 中的行为差异

%w 是唯一触发 error wrapping 的动词；%v、%s 等只是把 error 转成字符串拼进去，不保留原始 error 的引用关系，也就无法被 errors.Is 检测到。

errA := errors.New("original")
errB := fmt.Errorf("wrapped with %%w: %w", errA) // ✅ 可被 Is/As 穿透
errC := fmt.Errorf("wrapped with %%v: %v", errA) // ❌ 只是字符串，Unwrap() 返回 nil

使用 %w 时，errB.Unwrap() 返回 errA；而 errC.Unwrap() 返回 nil
即使嵌套多层，只要每层都用 %w，就能形成完整链路：fmt.Errorf("L1: %w", fmt.Errorf("L2: %w", io.EOF))
混用 %w 和 %v 会在中间断掉链：一旦某层用了 %v，其下游 error 就不可达

自定义 error 类型如何正确支持 wrapping？

如果你写了一个结构体 error（比如 type MyError struct { Msg string; Cause error }），要让它参与标准 error 链，必须显式实现 Unwrap() error 方法并返回 Cause 字段。

type MyError struct {
    Msg   string
    Cause error
}

func (e *MyError) Error() string { return e.Msg }
func (e *MyError) Unwrap() error { return e.Cause }

注意：返回 e.Cause 而不是 &e.Cause —— Unwrap 签名要求返回 error 接口，不是指针
如果 Cause 本身也支持 Unwrap，那么整个链就自然连通
不要在 Unwrap 中做额外逻辑（如日志、panic），它可能被频繁调用且预期无副作用

为什么 `errors.Unwrap` 有时返回 nil，有时 panic？

errors.Unwrap 函数本身不会 panic；但如果你对一个不支持 wrapping 的 error（如 errors.New("x")）调用它，它就返回 nil。真正容易 panic 的是误用 errors.As 或 errors.Is 时传入了非指针目标变量，或者在循环中没控制深度导致栈溢出（极少见，但自定义 Unwrap 实现有 bug 时可能发生）。