go中无内置多重错误类型，error接口仅支持单值；推荐用errors.join（go 1.20+）合并错误，或手动实现multierror结构体并支持unwrap，以确保可解构、可识别、可序列化。
Go 里没有内置的多重错误类型，error 是单值接口
Go 的 error 接口定义为 type error interface { Error() string }，天然只支持单个错误返回。所谓“多重错误”，其实是开发者自己组合多个错误的策略问题，不是语言层面的特性。直接返回多个 error 值（比如 func() (int, error, error)）既不规范，调用方也难以判断哪个错误有效。
用 errors.Join 合并多个错误（Go 1.20+）
errors.Join 是官方推荐的合并方式，返回一个实现了 error 接口的复合错误，支持嵌套、遍历和格式化输出。它会自动去重、忽略 nil 错误，并保留原始错误的因果链。
常见使用场景：
- 批量操作中多个子任务失败，需要汇总所有失败原因
- 资源清理阶段（
defer中关闭多个句柄）出现多个Close()错误 - 配置校验时多个字段同时出错
示例：
立即学习“go语言免费学习笔记（深入）”；
err1 := os.Remove("file1.txt")
err2 := os.Remove("file2.txt")
err := errors.Join(err1, err2) // 若两者都非 nil，err.Error() 类似 "remove file1.txt: no such file or directory; remove file2.txt: permission denied"
注意：errors.Join 返回的错误可被 errors.Is 和 errors.As 正确识别其子错误，但需配合 errors.Unwrap 或迭代器（如 errors.Unwrap 链或 errors.Values）提取具体成员。
手动实现 Unwrap 支持自定义多重错误（兼容旧版本或需控制行为）
若需 Go 1.20 之前支持，或想定制错误聚合逻辑（如带上下文前缀、按严重程度排序），可定义结构体并实现 error 和 Unwrap 方法：
type MultiError struct {
errs []error
}
func (m *MultiError) Error() string {
if len(m.errs) == 0 {
return ""
}
var msgs []string
for _, e := range m.errs {
if e != nil {
msgs = append(msgs, e.Error())
}
}
return strings.Join(msgs, "; ")
}
func (m *MultiError) Unwrap() []error {
return m.errs
}
这样就能用 errors.Is / errors.As 检查子错误，也能被 fmt.Printf("%+v", err) 展开显示嵌套结构。但要注意：必须确保 Unwrap 返回非 nil 切片（空切片可，nil 切片会导致 panic）；且不要在 Error() 中递归调用 Unwrap，否则可能栈溢出。
处理多重错误时最容易忽略的点
多重错误不是“打印出来就行”。实际工程中容易踩的坑包括：
- 用
fmt.Sprintf("%v", err)打印errors.Join结果，只看到顶层字符串，丢失嵌套结构 —— 应改用fmt.Printf("%+v", err)查看完整错误树 - 在 HTTP handler 中直接返回
errors.Join给前端，导致 JSON 序列化失败（因为没实现MarshalJSON）—— 需手动转成结构体再序列化 - 误以为
errors.Join(a, b) == errors.Join(b, a)—— 实际上顺序会影响Unwrap()返回的切片顺序，也影响Is匹配的优先级（从左到右） - 对
nil错误不做预过滤就传给Join—— 虽然安全，但会让日志里混入空字符串，干扰排查
真正关键的不是怎么“塞”多个错误进去，而是调用方是否能可靠地解构、分类、响应它们。这要求从错误生成、传递到消费全程保持一致性设计，而不是临时拼凑 fmt.Errorf("a: %v, b: %v", errA, errB) 这类字符串拼接。
