fmt.errorf("%w") 是唯一安全的错误包装方式，它通过%w动词触发标准包装逻辑，支持errors.is穿透；而%v、%s或字符串拼接会破坏错误链，导致unwrap()返回nil。
fmt.Errorf("%w") 是唯一安全的包裹入口
错误链不是靠字符串拼接出来的，而是靠 fmt.Errorf 的 %w 动词触发标准包装逻辑。用 %v、%s 或 + 拼接，哪怕内容一模一样，返回的都是 *fmt.errorString，Unwrap() 返回 nil，整条链立刻断裂。
-
fmt.Errorf("read config: %w", err)✅ 支持errors.Is穿透 -
fmt.Errorf("read config: %v", err)❌errors.Is(err, fs.ErrNotExist)永远返回false -
"read config: " + err.Error()❌ 不是error类型，连errors.Unwrap都调不了
Go 1.22 起支持多个 %w，但需显式标注：fmt.Errorf("a: %w, b: %w", errA, errB)；旧版本仍只认一个。
自定义错误必须显式实现 Unwrap() 才能接入链
结构体错误默认是“黑盒”，errors.Is 只能匹配它自身，无法穿透到内部字段。除非你告诉运行时：“我包裹了这个错误”。漏掉 Unwrap() 方法是最常见失误——表面 fmt.Errorf("xxx: %w", myErr) 能编译，但上游 errors.Is 全失效。
- 返回字段中保存的
error值，不能返回nil（除非确实无底层错误） - 不能返回硬编码错误（如
io.ErrUnexpectedEOF），否则会误导遍历逻辑 - 若
Cause本身是nil，Unwrap()返回nil合法，errors.Is会继续匹配类型自身
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type ValidationError struct {
Msg string
Code int
Cause error // 必须存为 error 类型
}
func (e *ValidationError) Unwrap() error { return e.Cause }
errors.Unwrap 只解一层，别指望它自动递归
errors.Unwrap 设计上就是单步操作——它不判断环、不跳过 nil、不递归向下。裸调 errors.Unwrap(err) 后不检查返回值，可能对 nil 再调一次导致 panic。
- 正确写法：
for err != nil { ; err = errors.Unwrap(err) } - 绝大多数场景根本不需要手动
Unwrap：用errors.Is(err, target)或errors.As(err, &target)更安全，它们内置环检测和完整遍历 - 自定义错误若未实现
Unwrap() error，errors.Unwrap直接返回nil，不会尝试反射或 fallback
errors.Join 不适合链路追踪
errors.Join 不适合链路追踪，因其仅聚合错误而不保留调用顺序、嵌套层级和上下文字段（如 traceID、spanID），无法构建可追溯的错误传播路径。它返回的是 []error，而标准库的 fmt.Errorf("%w", ) 只接受单个 error。
-
errors.Join适合日志聚合或批量校验失败汇总（比如配置项校验返回所有错误） - 真正要构建错误链，必须靠手动嵌套：
fmt.Errorf("at db layer: %w", innerErr)一层套一层 - 若强行用
errors.Join做链路追踪，后续调用errors.Unwrap会丢失结构
链路追踪依赖的是错误传播路径，不是错误集合；而 Unwrap() 的语义是“谁封装了谁”，不是“哪些错误同时发生”。这点容易被忽略，但恰恰是调试时卡住的关键。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
