errors.join 是 go 1.20 引入的多错误聚合函数，用于合并多个 error 并保留各自类型与上下文，适用于并发失败、多子请求错误等场景；它支持 errors.is/as 全面匹配，errors.unwrap 仅返回首个非 nil 错误，参数顺序影响展开优先级。
errors.Join 是什么，什么时候必须用它
errors.Join 在 Go 1.20 引入，用来把多个 error 值合并成一个可展开的单一错误。它不是简单拼字符串，而是保留每个子错误的原始类型和上下文——这点很关键。你遇到并发任务批量失败、HTTP 多个子请求出错、或者校验多个字段都无效时，errors.Join 就是比 fmt.Errorf 拼接更合适的选择。
- 如果只是单个错误，别硬套
errors.Join；它不省事，反而增加开销 - 子错误里有自定义错误类型（比如实现了
Unwrap或Is方法），errors.Join能让这些方法继续生效 - 它返回的错误支持
errors.Is和errors.As向下查找任意子错误，这是字符串拼接做不到的
怎么正确调用 errors.Join，参数顺序有影响吗
errors.Join 接收可变参数 ...error，顺序会影响 errors.Unwrap 的展开行为：它只返回第一个非 nil 错误作为主展开项，其余打包进内部列表。所以如果你希望某个错误在 errors.Unwrap 时优先暴露，就把它放第一个。
- 所有参数为
nil时，errors.Join返回nil，不用额外判空 - 中间有
nil值会被跳过，不影响结果（比如errors.Join(err1, nil, err2)等价于errors.Join(err1, err2)） - 不要传入同一个错误实例多次，虽然不会 panic，但会让
errors.Is判定重复匹配，逻辑变难懂
err := errors.Join(io.EOF, fmt.Errorf("timeout"), os.ErrPermission)
// errors.Is(err, io.EOF) → true
// errors.Is(err, os.ErrPermission) → true
// errors.Unwrap(err) → io.EOF（仅第一个）errors.Join 和 fmt.Errorf("%w, %w") 的核心区别
fmt.Errorf("%w, %w") 是格式化包装，本质是单层嵌套；而 errors.Join 是多路并行聚合。前者只能 Unwrap 出一个错误，后者能遍历全部子错误。
-
fmt.Errorf的%w只接受一个错误，强行写多个会编译报错：too many %w verbs -
errors.Join返回的错误，errors.Unwrap只返回第一个，但errors.Unwrap配合循环或errors.Is能穿透全部 - 日志打印时，
errors.Join默认输出带换行的结构化文本（Go 1.20+ 默认格式），fmt.Errorf就是纯字符串拼接
容易被忽略的兼容性和调试陷阱
Go 1.19 及更早版本没有 errors.Join，直接使用会编译失败。如果项目还要兼容旧版本，不能只靠构建 tag 条件编译——因为调用方可能用旧版 stdlib 解析错误（比如日志库、gRPC 错误处理），导致 errors.Is 失效。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖
errors.Join返回值的底层结构（比如认为它一定是*joinError），Go 不承诺导出类型稳定 - 在 HTTP handler 中聚合错误后直接返回，客户端看到的 status code 还是 500，
errors.Join不改变错误级别，得自己控制 - 使用
log.Printf("%+v", err)查看详细堆栈时，errors.Join的每个子错误堆栈都会展开，可能刷屏，建议搭配errors.Format（Go 1.22+）或手动限深
事情说清了就结束。
