Go语言多错误合并处理方法

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《Golang多错误合并处理技巧》，聊聊，我们一起来看看吧！

Go 1.20 引入 errors.Join 作为官方推荐的多错误聚合标准方式，支持嵌套、去重、nil 忽略及完整 errors.Is/As 兼容性，取代字符串拼接和自定义 MultiError。

Go 1.20 引入了 errors.Join，它才是标准、安全、可展开的多错误聚合方式；此前社区常用的自定义 MultiError 类型或字符串拼接（如 fmt.Errorf("a: %w, b: %w", errA, errB)）既不支持错误遍历，也无法被 errors.Is/errors.As 正确识别。

用 errors.Join 合并多个错误

这是 Go 官方推荐的唯一标准方法，返回一个实现了 error 接口且内部保存错误切片的不可变值。它支持嵌套、去重（空错误会被跳过），且所有标准错误工具链都能正常工作。

常见错误现象：手动拼接字符串（fmt.Sprintf("err1: %v; err2: %v", e1, e2)）导致无法用 errors.Is 判断原始错误类型，也无法提取底层错误。

• errors.Join 会自动忽略 nil 错误，无需提前过滤
• 传入单个错误时，直接返回该错误（不包装），行为符合直觉
• 结果错误的 Error() 方法按顺序拼接各子错误的 Error() 输出，用换行分隔
• 若需自定义分隔符或格式，应自行封装，而非绕过 errors.Join

errA := fmt.Errorf("failed to read config")
errB := io.EOF
errC := nil

multiErr := errors.Join(errA, errB, errC) // 等价于 errors.Join(errA, errB)
fmt.Println(multiErr.Error())
// 输出：
// failed to read config
// EOF

fmt.Println(errors.Is(multiErr, io.EOF)) // true
fmt.Println(errors.As(multiErr, &errB)) // true

遍历和检查 errors.Join 返回的错误

不能直接类型断言为某个私有结构体——errors.Join 的具体实现是未导出的，必须通过标准接口操作。

使用场景：需要分别处理每个底层错误（如日志记录、分类上报、条件重试）。

• 用 errors.Unwrap 只能拿到第一个子错误，不适用
• 正确方式是调用 errors.Unwrap 配合类型判断，或更可靠地使用 errors.As/errors.Is 逐个探测
• 若真需枚举全部子错误，目前没有公开 API；可借助 fmt.Printf("%+v", err) 查看调试信息，但生产代码中不应依赖此行为
• 第三方库如 github.com/hashicorp/errwrap 提供了 Errors() 方法，但会破坏标准兼容性，不建议在新项目中引入

避免在 defer 中无意识覆盖错误

常见错误现象：函数结尾用 defer 关闭资源，但关闭失败时直接赋值给返回错误变量，把原本的主错误覆盖掉了。

使用场景：数据库事务、文件写入、HTTP handler 中需确保 cleanup 的地方。

• 不要写 if cerr := f.Close(); cerr != nil { err = cerr } —— 这会丢掉原始错误
• 应改用 err = errors.Join(err, f.Close())，让两个错误共存
• 注意：如果 f.Close() 本身可能 panic（极少见），需先 recover，否则 errors.Join 不会执行
• 对多个 cleanup 操作，累积调用 errors.Join 即可，它接受任意数量参数

func processFile(name string) error {
    f, err := os.Open(name)
    if err != nil {
        return err
    }
    defer func() {
        // 正确：合并，不覆盖
        if closeErr := f.Close(); closeErr != nil {
            err = errors.Join(err, closeErr)
        }
    }()

    // ... 主逻辑
    return nil
}

真正容易被忽略的是：errors.Join 返回的错误在被多次传递后，其内部错误链长度可能远超预期，尤其在深层嵌套调用 + 多次 Join 后。打印时可能输出几十行错误堆栈，但 errors.Is 仍只匹配最外层的“存在性”，不会递归穿透所有层级——这点和 fmt.Errorf("%w", inner) 的单层包装有本质区别。需要精细控制错误传播深度时，得靠业务逻辑做裁剪，而不是依赖工具函数自动降噪。

以上就是《Go语言多错误合并处理方法》的详细内容，更多关于的资料请关注golang学习网公众号！