go 1.20 引入的 errors.join 是官方推荐的多错误聚合标准方式，支持嵌套、去重、nil 忽略及完整 errors.is/as 兼容性，取代字符串拼接和自定义 multierror。
Go 1.20 引入的 errors.Join 是目前最稳妥、语义最清晰的多错误合并方式，替代手写 fmt.Errorf 拼接或自定义错误类型；但直接套用仍可能踩坑——比如嵌套调用时丢失原始错误链、errors.Is 判断失效、或与旧版错误处理逻辑不兼容。
什么时候必须用 errors.Join 而不是 fmt.Errorf？
当你需要保留多个底层错误的独立性，并支持后续用 errors.Is 或 errors.As 分别匹配其中任意一个时，errors.Join 是唯一选择。用 fmt.Errorf("failed: %v, %v", err1, err2) 会把错误转成字符串，彻底丢失类型和底层错误信息。
- 典型场景：并发请求中多个 goroutine 同时失败，需汇总所有错误供上层分类处理
-
errors.Join返回的错误实现了Unwrap方法，返回一个错误切片，因此能被标准错误检查函数识别 - 注意：
errors.Join(nil, err)等价于err；errors.Join(nil, nil)返回nil，这点和fmt.Errorf不同
errors.Join 的嵌套调用为什么会让 errors.Is 失效？
因为 errors.Join 的展开是扁平的——它只展开一层，不会递归解包嵌套的 Join 错误。如果你写了 errors.Join(err1, errors.Join(err2, err3))，外层 errors.Is 只能命中 err1 和内层 Join 实例，而无法直接命中 err2 或 err3。
- 正确做法：始终展平再合并，例如
errors.Join(err1, err2, err3) - 若必须动态收集，用切片累积后一次性传入：
errors.Join(errs...) - 避免在中间层反复
Join，尤其不要在 defer 或包装函数里无意识嵌套
与 github.com/pkg/errors 的 Wrap / MultiError 怎么共存？
不能混用。原生 errors.Join 返回的是 interface{ Unwrap() []error }，而 pkg/errors.MultiError 是自定义结构体，两者 Unwrap 签名不同（后者返回 []error，前者返回 []error 但类型不兼容），导致 errors.Is 在跨库调用时跳过 pkg/errors 的错误。
- 迁移建议：新项目直接用
errors.Join；存量项目逐步替换，优先改调用方，再改错误生成方 - 临时兼容：若必须混合，用
errors.Unwrap手动提取 pkg/errors 的子错误，再拼进errors.Join - 特别注意：
pkg/errors.Wrap包装后的错误，其Unwrap()返回单个 error，不是切片，所以不能直接丢进errors.Join当作多错误源
真正麻烦的不是怎么调用 errors.Join，而是它暴露了 Go 错误处理中长期被忽略的问题：错误是否可组合、是否可逆向追溯、是否被日志或监控系统正确解析。一个 Join 调用写错位置，就可能导致上游 errors.Is(io.EOF) 判断永远为 false —— 这种问题往往在线上压测时才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
