fmt.Errorf 不能直接用 %w 包装 nil 错误，因为会 panic；error.Wrap 与 %w 本质不同：前者带栈但不兼容原生 errors.Is()，后者无栈但支持标准错误链；errors.Is() 失效常因非标准包装中断链；性能敏感场景应控制包装深度≤4层。
fmt.Errorf 为什么不能直接用 %w 包装 nil 错误
因为 fmt.Errorf 遇到 %w 对应的值是 nil 时，会 panic，不是返回 nil 错误。这是最容易被忽略的崩溃点——尤其在错误链中间态未做判空时。
常见错误现象：panic: interface conversion: interface {} is nil, not error
- 使用场景：封装函数内部错误，比如
io.ReadFull失败后想加前缀再返回 - 必须先判断原始错误是否为
nil，再决定是否用%w - 错误写法：
return fmt.Errorf("read header failed: %w", err)（当err == nil时崩） - 正确写法：
if err != nil { return fmt.Errorf("read header failed: %w", err) }; return nil
error.Wrap 和 fmt.Errorf("%w") 的本质区别在哪
error.Wrap 是第三方库（如 github.com/pkg/errors）提供的函数，而 fmt.Errorf("%w") 是 Go 1.13+ 原生错误包装机制，二者行为不兼容。
关键差异在于错误链遍历和底层结构：
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Errorf("%w")生成的是*fmt.wrapError，支持errors.Unwrap()和errors.Is()，但不带堆栈 -
error.Wrap生成的是带调用栈的自定义 error 类型，errors.Unwrap()能取到下层，但errors.Is()在跨包比较时可能失效（因类型不同） - 混用会导致
errors.As()失败：比如用fmt.Errorf包装后，再用pkg/errors.Cause()取不到原始错误 - 建议全项目统一：新项目优先用原生
%w，老项目迁移需检查所有pkg/errors调用点
用 %w 包装错误后，为什么 errors.Is() 有时不生效
因为 errors.Is() 依赖错误链中每个节点都实现了 Unwrap() error 方法，并且最终能比对到目标错误值。如果中间某层用了非标准包装（比如字符串拼接、自定义 struct 但没实现 Unwrap），链就断了。
典型踩坑场景：
- 手动拼接错误：
fmt.Errorf("failed: " + err.Error())—— 完全丢失原始错误，errors.Is()必然失败 - 用
%v或%s替代%w：fmt.Errorf("wrap: %v", err)—— 不触发包装，只是格式化输出 - 嵌套两层以上但其中一层返回
nil：Unwrap()返回nil会让errors.Is()提前终止查找 - 验证方式：
errors.Unwrap(err)看是否得到预期下层错误；或用fmt.Printf("%+v", err)查看完整链（需原生支持或用github.com/hashicorp/errwrap）
性能敏感场景下，该不该用 %w 包装错误
该，但要控制深度。每次 %w 包装都会分配一个新 error 对象，且 errors.Is()/errors.As() 需要线性遍历整个链。
实操建议：
- 日志或调试场景：可以多层包装，便于追溯上下文
- 高频路径（如网络请求循环、codec 解析）：避免在 tight loop 中反复
fmt.Errorf，考虑提前构造好带前缀的 error 变量复用 - 最大推荐深度 ≤ 4 层，超过后
errors.Is()开销明显上升（实测 10 层链比 2 层慢 3× 以上） - 若只需标记上下文、不需
Is/As，用fmt.Sprintf+ 原始错误字段更轻量（但失去类型语义）
fmt.Errorf("%s: %v", msg, err) 其实悄悄切断了整条错误诊断链。 
