Golang函数如何优雅地处理多个error？错误链与errors.Join【方法】-Golang-PHP中文网

应使用 errors.join 而非手动拼接字符串来合并多个 error，因其保留原始错误类型、堆栈及可判断性，支持 errors.is/as 递归检查，且自动忽略 nil；但需注意避免 defer 中误用及确保子错误用 %w 包装以维持链式可识别性。

golang函数如何优雅地处理多个error？错误链与errors.join【方法】

多个error需要同时返回时，用 `errors.Join` 而不是手动拼接字符串

Go 1.20 引入的 errors.Join 是处理多个 error 的标准方式。它不是简单把错误拼成字符串，而是构建一个可遍历、可判断、可展开的错误链。手动用 fmt.Errorf("a: %v; b: %v", errA, errB) 会丢失原始 error 类型和堆栈，后续无法用 errors.Is 或 errors.As 判断。

errors.Join 返回的 error 实现了 Unwrap 方法，支持多层嵌套展开
传入 nil 会被自动忽略，不用提前过滤
如果所有参数都是 nil，返回 nil，符合 Go 错误语义
示例：err := errors.Join(err1, err2, err3)，之后可用 errors.Is(err, someErr) 检查任一子错误是否匹配

用 `errors.Is` 和 `errors.As` 判断 `errors.Join` 结果时，会递归检查所有子错误

这是 errors.Join 的核心价值：它让“组合错误”仍保持语义可识别性。比如你封装了一个批量操作函数，内部多个 goroutine 各自返回 error，用 Join 合并后，调用方仍能统一判断是否含某种特定错误类型。

Golang Google Wire

在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface

下载

errors.Is(err, os.ErrPermission) 在 err 是 errors.Join 结果时，会逐层 Unwrap 直到找到匹配项或结束
errors.As(err, &target) 同样递归查找，只要任一子 error 可转为 target 类型，就返回 true
注意：errors.Unwrap 只返回第一个子 error（按传入顺序），但 Is/As 是全量扫描

不要在 defer 中直接用 `errors.Join` 累加 error，容易漏掉 nil 判断或覆盖逻辑

常见反模式：在循环里反复 err = errors.Join(err, stepErr)，尤其配合 defer 使用时，容易因初始 err 是 nil 导致第一次调用后变成非 nil，后续又意外覆盖。

更安全的做法是收集 error 切片，最后一次性 Join：errs = append(errs, stepErr)，结尾用 errors.Join(errs...)
如果必须边执行边合并，记得判空：if stepErr != nil { err = errors.Join(err, stepErr) }
特别注意 defer 里的赋值：若函数签名返回 err error，且 defer 中修改 err，要确保不会因多次执行 defer 而重复 Join 同一个 error

当需要区分错误来源或保留上下文时，`errors.Join` 不够用，得用自定义 error 包装

errors.Join 解决的是“有哪些错误”，但不解决“每个错误来自哪一步”。比如批量删除文件，你想知道 “file_a.txt: permission denied”、“file_b.txt: no such file”，这时单纯 Join 会丢失 key 信息。

推荐组合使用：fmt.Errorf("delete %s: %w", filename, realErr) 包装每个子错误，再 Join 这些带上下文的 error
这样既保留结构化信息，又支持 errors.Is 对底层错误（如 os.ErrNotExist）做判断
避免把所有信息塞进一个 error 字符串——那会让 Is/As 失效，也难以自动化解析