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 的具体实现是未导出的，必须通过标准接口操作。
立即学习“go语言免费学习笔记（深入）”；
使用场景：需要分别处理每个底层错误（如日志记录、分类上报、条件重试）。
- 用
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) 的单层包装有本质区别。需要精细控制错误传播深度时，得靠业务逻辑做裁剪，而不是依赖工具函数自动降噪。
