fmt.Errorf(“%w”) 专用于错误包装，仅接受实现unwrap() error的error类型；传nil导致链断裂，传非error类型编译失败，混用%w与%s易引发判断混乱，嵌套过深影响性能与调试。
fmt.Errorf(“%w”) 为什么不能随便套用
fmt.Errorf 里的 %w 不是普通占位符，它专用于错误包装（error wrapping），只有传入实现了 Unwrap() error 方法的值才合法。传 nil、字符串、结构体或没实现 Unwrap 的自定义错误，运行时不会报错，但后续调用 errors.Is 或 errors.As 会静默失败。
- 传
nil：包装后得到一个“空包装”，errors.Unwrap()返回nil，链断裂 - 传非
error类型（比如"failed"）：编译不通过（类型检查失败） - 传未包装的原始错误（如
io.EOF）：可以，但没增加上下文，白用%w - 正确做法：只传另一个
error，且最好本身也支持包装（比如来自fmt.Errorf("%w", ...)或errors.New包装过的）
什么时候该用 %w，什么时候该用 %s
用 %w 的唯一目的，是让错误可追溯、可诊断——不是为了“看起来像链式”。如果下游要靠 errors.Is(err, io.EOF) 判断业务逻辑，或用 errors.As(err, &myErr) 提取原始错误，就必须用 %w；否则用 %s 或直接拼字符串更清晰、更轻量。
- 需要保留原始错误语义和类型信息 → 用
%w - 只是记录上下文（比如“在解析 config.json 时出错”），不关心原始错误细节 → 用
%s+err.Error() - 混用风险：同一错误里既用
%w又用%s包装同一个底层错误，会导致链重复或判断混乱
示例：
err := fmt.Errorf("failed to open file: %w", os.Open(name)) // ✅ 可追溯 err := fmt.Errorf("failed to open file: %s", os.Open(name).Error()) // ❌ 丢失类型，无法 Is/As嵌套三层以上 %w 容易踩的坑
go 错误链没有深度限制，但实际中嵌套超 3 层就容易出问题：日志打印时默认只展开一层（fmt.printf("%+v", err) 才显示完整链），调试器可能截断，而且 errors.Is 在长链中匹配效率线性下降。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is会逐层Unwrap()直到nil，链越长越慢（尤其在 hot path） - 多个中间层都用
%w包装同一错误，可能导致errors.As提取出错（比如两次包装后，第二次As可能命中中间层而非原始层） - 日志系统（如 zap、logrus）默认不递归展开
%w链，需显式配置或用%+v
建议：单次调用最多包装一次，必要时用自定义错误类型控制链结构，而不是靠堆 fmt.Errorf("%w", fmt.Errorf("%w", ...))。
自定义错误类型想支持 %w 怎么写
只要实现 Unwrap() error 方法，就能被 %w 接收。但注意：返回 nil 表示链终止；返回其他 error 才继续展开。
- 必须返回字段持有的错误，不能返回新构造的错误（否则破坏链一致性）
- 如果错误有多个底层原因（比如并发操作中多个子错误），
Unwrap只能返回一个 —— 这是设计限制，别试图绕过 - 不要忘记导出方法名：
Unwrap首字母必须大写，否则外部包不可见
示例：
type MyError struct { msg string cause error } func (e *MyError) Error() string { return e.msg } func (e *MyError) Unwrap() error { return e.cause } // ✅ 正确 // 调用：fmt.Errorf("handling failed: %w", &MyError{msg: "boom", cause: io.EOF})链式包装真正难的不是语法，是判断哪一层该留、哪一层该断——多数人的问题不在怎么写，而在没想清楚谁才是“原始错误”。