必须用%w才能形成可展开的错误链，否则errors.Is和errors.As失效；%w仅支持一个且须在末尾，多%w编译失败；不可对nil或非error类型使用%w；fmt.Errorf+%w表因果包装，errors.Join表并列聚合。
fmt.Errorf 包装错误时为什么必须用 %w
不用 %w 就无法形成可展开的错误链，errors.Is 和 errors.As 都会失效。比如底层返回 os.ErrNotExist，你用 fmt.Errorf("read config: %v", err) 包一层，上层调用 errors.Is(err, os.ErrNotExist) 会返回 false——因为字符串拼接后原始错误对象已丢失。
正确做法是显式使用 %w 动词，它告诉 fmt.Errorf 把右侧错误作为「包装目标」存入新错误的内部字段：
err := os.Open("config.json")
if err != nil {
return fmt.Errorf("failed to open config file: %w", err)
}
这时新错误既保留原始错误类型，又附带了上下文描述。
多个 %w 会导致什么问题
fmt.Errorf 只支持一个 %w，且必须是最后一个动词。写成 fmt.Errorf("a: %w, b: %w", err1, err2) 会编译失败，报错：cannot use %w more than once。
立即学习“go语言免费学习笔记（深入）”；
如果需要串联多个错误（例如：网络请求失败 → 解析响应失败 → 校验签名失败），应逐层包装：
- 先用
%w包装最内层错误 - 再用结果去包装外层，依此类推
- 避免试图在一个
fmt.Errorf中塞多个错误源
错误示例（编译不通过）：
fmt.Errorf("http: %w, json: %w", httpErr, jsonErr) // ❌
正确方式（链式包装）：
err := fmt.Errorf("parse response: %w", jsonErr)
err = fmt.Errorf("call api: %w", err)
什么时候不该用 %w：非错误类型或 nil
%w 要求参数必须是实现了 error 接口的值，传入 nil 或非错误类型（如 string、int）会 panic 或编译报错。
常见误用场景：
- 忘记检查
err是否为nil就直接%w——运行时报panic: interface conversion: interface {} is nil, not error - 把自定义结构体（未实现
Error()方法）当错误传给%w - 用
%w拼接日志消息，比如fmt.Errorf("user %d: %w", id, err)，但id不是错误
安全写法：
if err != nil {
return fmt.Errorf("process user %d: %w", id, err)
}
// 不在 if 外写 %w
fmt.Errorf 与 errors.Join 的区别
fmt.Errorf + %w 是单向包装（A 包装 B），而 errors.Join 是并列聚合（A 和 B 平级共存）。两者用途完全不同：
- 用
%w表达「因果关系」：因为 B 失败，所以 A 失败 - 用
errors.Join表达「多个独立失败」：A 失败了，B 也失败了，都得上报
例如批量操作中部分失败：
var errs []error
for _, item := range items {
if err := process(item); err != nil {
errs = append(errs, fmt.Errorf("item %v: %w", item.ID, err))
}
}
if len(errs) > 0 {
return errors.Join(errs...) // ✅ 返回所有失败项的聚合错误
}
这里每个子错误仍用 %w 包装，最后再用 Join 合并——不是替代关系，而是配合使用。
真正容易被忽略的是：%w 不会自动递归展开嵌套错误，errors.Unwrap 只解一层；要遍历整个链，得用 errors.Is 或手动循环 Unwrap。这点在调试和日志打印时特别关键。
