errors.Join 支持多错误并列聚合，可多次 Unwrap 展开；fmt.Errorf(%w) 仅单层包装，且 %w 后 nil 会 panic；errors.Is/As 可跨层级判断，日志推荐 %+v 打印全链。
Go 1.20+ 中 errors.Join 和 fmt.Errorf 的嵌套写法区别
直接用 fmt.Errorf 套 %w 是最常见错误链构建方式，但它只支持单个包装；而 errors.Join 能把多个独立错误合并成一个可展开的链。比如数据库事务失败时同时遇到连接断开、约束冲突、超时三个错误，errors.Join(errA, errB, errC) 生成的错误对象能被 errors.Unwrap 多次调用，逐层拿到原始错误。
注意：用 %w 包装时，被包装的错误必须是非 nil；否则 fmt.Errorf("xxx: %w", nil) 会 panic —— 这是线上常被忽略的崩溃点。
-
fmt.Errorf("read failed: %w", io.ErrUnexpectedEOF)→ 单层包装，适合“原因唯一”的场景 -
errors.Join(io.ErrUnexpectedEOF, sql.ErrNoRows)→ 多错误并列，适合聚合校验或批量操作失败 - 若混用（如
fmt.Errorf("batch: %w", errors.Join(a,b))），外层仍只能Unwrap一次，内层才可继续展开
用 errors.Is 和 errors.As 判断链中任意层级的错误类型
传统 == 或类型断言只能比对最外层错误，而 errors.Is(err, os.ErrNotExist) 会自动遍历整个链，只要某一层等于目标值就返回 true；errors.As(err, &target) 同理，能在链中找到第一个匹配的结构体并赋值。
典型误用：在 HTTP handler 中写 if err == context.Canceled —— 如果中间经过了 fmt.Errorf("timeout: %w", ctx.Err())，这个判断就失效了，必须改用 errors.Is(err, context.Canceled)。
立即学习“go语言免费学习笔记（深入）”；
- 不要在循环里反复调用
errors.Is做高频判断，它内部有递归开销；可先errors.Unwrap提取关键错误缓存 -
errors.As对指针类型安全，但对接口类型（如自定义 error 接口）不生效，需确保目标变量是指向具体 struct 的指针 - 如果链中存在重复错误（比如两次包装同一个
os.PathError），errors.As只返回第一次匹配的结果
日志中打印完整错误链不能只靠 err.Error()
err.Error() 默认只输出最外层消息，丢失所有上下文。要打印全链，得手动递归调用 errors.Unwrap，或者用第三方库如 github.com/pkg/errors（Go 1.13+ 原生已覆盖大部分需求，不建议额外引入）。
生产环境推荐做法：用 fmt.Printf("%+v", err)，它会触发原生错误的格式化器，显示每层的文件/行号和消息（前提是各层都用 %w 或 errors.Join 构建）。
- 避免在日志里拼接
err.Error() + " | " + cause.Error()，这容易漏掉中间层，且破坏堆栈可解析性 - 如果用了 zap/logrus 等结构化日志库，应把错误链整体传入字段（如
logger.Error("db query failed", zap.Error(err))），它们通常内置了链式展开逻辑 - 调试时可用
debug.PrintStack()配合错误链，但别在生产代码里留着，性能代价高
自定义错误类型参与链式传递的两个必要条件
你的结构体错误想被 errors.Is 和 errors.As 正确识别，必须同时满足：Unwrap() error 方法返回下一层错误，且实现 Error() string。缺一不可。
常见错误是只实现了 Unwrap 却忘了 Error，导致 fmt.Printf("%v", myErr) 输出空字符串，或 errors.Is 判定失败。
- 如果错误不需要包装其他错误（即叶子节点），
Unwrap()应返回nil，不是省略方法 - 不要在
Unwrap里做副作用（如重试、打日志），它可能被多次调用 - 若结构体包含敏感字段（如密码、token），
Error()方法里记得脱敏，否则全链打印时会泄露
