Go 1.20+ 怎么用 errors.Join 合并多个错误
直接用 errors.Join，它专为多错误聚合设计，返回一个实现了 error 接口的组合错误值，支持嵌套展开和格式化输出。
常见错误是传入 nil：如果某个错误变量是 nil，errors.Join 会自动忽略它，不用提前判空；但若所有参数都是 nil，结果也是 nil，容易误判为“没出错”。
- 只接受
error类型参数，传string或其他类型会编译报错 - 顺序敏感：
errors.Join(errA, errB)和errors.Join(errB, errA)的字符串输出顺序不同，影响日志可读性 - 性能开销极小，底层是切片拼接，无反射或堆分配
示例：
err := errors.Join(io.ErrUnexpectedEOF, fmt.Errorf("parsing failed")) 输出类似 "unexpected EOF; parsing failed"。
老版本 Go（
不能用 errors.Join，得手动构造带 Unwrap 方法的结构体，或者用社区方案如 pkg/errors（已归档）或 go-errors/errors。但最轻量、最可控的方式是自定义一个简单聚合器。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是忘记实现 Unwrap —— 没它就无法被 errors.Is 或 errors.As 正确识别子错误。
- 必须返回
[]error切片，不能只返回第一个或最后一个 - 不要在
Error()方法里做耗时操作（比如格式化大量日志），否则影响性能 - 避免在循环中反复调用
errors.Join（老版本不存在，但有人模仿实现时会递归拼接导致栈溢出）
示例（兼容 Go 1.13+）：
type MultiError []error
func (m MultiError) Error() string { return "multiple errors" }
func (m MultiError) Unwrap() []error { return []error(m) }
errors.Is 和 errors.As 对聚合错误是否有效
有效，但只作用于直接子错误，不递归穿透多层嵌套。比如 errors.Join(a, errors.Join(b, c)) 中，errors.Is(err, b) 返回 true，但 errors.Is(err, c) 是 false —— 因为 c 是二级子错误。
这意味着：聚合层级越深，错误检测越不可靠；生产环境建议扁平化聚合，最多一层嵌套。
-
errors.As同样只匹配第一层子错误，不会解包再解包 - 若需深度匹配，得自己写递归遍历逻辑，但多数场景没必要
- 日志打印时用
%+v可看到完整嵌套结构，%v只显示顶层摘要
HTTP handler 中聚合错误后怎么返回合理响应
别直接把 errors.Join 结果塞进 http.Error —— 默认只调 Error()，丢失结构信息，前端无法区分具体失败步骤。
更实用的做法是：聚合后判断是否含关键错误（如 context.Canceled、io.EOF），再决定状态码；同时用结构化 JSON 返回所有错误详情。
- HTTP 状态码应反映最严重错误，不是聚合数量；两个
400 Bad Request错误仍该返回400，不是500 - 不要暴露内部错误细节给客户端（如文件路径、数据库语句），聚合前先清洗
- 若用 Gin/Echo 等框架，注意它们的
Error方法可能覆盖原始 error 值，需手动透传
示例响应结构：
{"code": 400, "message": "validation failed", "details": ["email invalid", "phone missing"]}
聚合错误本身不难，难的是保持错误语义清晰、调试路径可追溯。很多人只关注“怎么拼起来”，却忽略“拼完之后谁来读、怎么读”。真正卡住人的，往往是日志里看到一串 "multiple errors" 却找不到哪个分支实际失败了。 
