Golang错误处理与传播技巧详解

一分耕耘，一分收获！既然都打开这篇《Golang错误判断与传播技巧》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新Golang相关的内容，希望对大家都有所帮助！

errors.Is只能判断是否包含目标错误值，依赖Unwrap链逐层比较值相等性，不支持类型断言；自定义错误需实现Unwrap或用%w包装才能被识别。

errors.Is 为什么不能判断自定义错误类型

errors.Is 只能识别通过 fmt.Errorf 带 %w 动词包装的错误，或实现了 Unwrap() error 方法的错误。它不依赖类型断言，而是靠逐层调用 Unwrap() 向下查找是否“包含”某个目标错误值。

如果你直接返回 &MyError{} 或 errors.New("xxx")，它没有 Unwrap 方法，errors.Is(err, myErr) 就永远是 false，哪怕 err 就是那个 *MyError 实例。

• 正确做法：用 fmt.Errorf("wrap: %w", myErr) 包装后再返回
• 错误做法：直接 return &MyError{} 后期望 errors.Is(err, &MyError{}) 成功
• 注意：errors.Is 比较的是错误值（value），不是类型；若想按类型判断，请用 errors.As

errors.Is 和 errors.As 的核心区别在哪

errors.Is 判断“是否等于某个错误值”，常用于预定义的哨兵错误（如 io.EOF、os.ErrNotExist）；errors.As 则尝试把错误链中任意一层“转换为指定类型”，用于提取自定义错误结构体中的字段。

• errors.Is(err, io.EOF) → 查找错误链里有没有 io.EOF 这个具体值
• errors.As(err, &e) → 查找错误链里有没有能赋值给 *MyError 的那一层，并把值拷贝进 e
• 两者都从最外层错误开始，逐层 Unwrap()，但匹配逻辑完全不同
• 如果错误没实现 Unwrap()，它们都只检查当前层

哨兵错误必须是变量，不能是函数返回值

定义哨兵错误时，必须用 var 声明全局变量，例如 var ErrNotFound = errors.New("not found")。如果写成函数返回 errors.New("not found")，每次调用都生成新对象，errors.Is(err, ErrNotFound()) 必然失败——因为比较的是指针或底层字符串地址，不是语义相等。

• ✅ 正确：var ErrTimeout = errors.New("timeout")
• ❌ 错误：func ErrTimeout() error { return errors.New("timeout") }
• ⚠️ 补充：使用 fmt.Errorf("%w", ErrTimeout) 包装后，errors.Is 仍可识别原哨兵值

嵌套多层错误时 errors.Is 的实际行为

errors.Is 不止看第一层，它会递归调用 Unwrap() 直到返回 nil，只要中间任何一层 == 目标错误，就返回 true。这意味着它适合判断“是否由某类错误引发”，但不适合精确定位哪一层出错。

err := fmt.Errorf("db query failed: %w", fmt.Errorf("network error: %w", io.EOF))
errors.Is(err, io.EOF) // true
errors.Is(err, fmt.Errorf("network error: %w", io.EOF)) // false —— 因为是值比较，不是类型或结构匹配

• 每一层包装都应使用 %w，否则断开 Unwrap 链，errors.Is 就无法穿透
• 不要在中间层用 fmt.Errorf("msg: %v", err)，这会丢失原始错误引用
• 若需保留上下文又不想干扰 Is 判断，可用 fmt.Errorf("msg: %w", err) 并确保被包装错误支持 Unwrap

终于介绍完啦！小伙伴们，这篇关于《Golang错误处理与传播技巧详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！