fmt.Errorf("%w") 包装 nil 错误会 panic，因 %w 要求右侧必须为非nil error；混用 errors.Wrap 与 %w 导致错误链断裂、errors.Is/As 失效；应显式判空、控制包装深度≤4层以平衡可追溯性与性能。
fmt.Errorf("%w") 包装 nil 错误会 panic
直接用 fmt.Errorf("msg: %w", err) 且 err 为 nil 时，Go 运行时会立即 panic，错误信息类似 panic: interface conversion: interface {} is nil, not error。这不是设计疏漏，而是明确的语义约束：%w 要求右侧必须是 error 类型值，nil 不满足该接口断言。
常见于封装中间层逻辑时，比如：
- 调用
io.ReadFull后未判空就直接包装 - 多个子操作中某步成功（返回
nil），但统一走同一错误返回路径
正确做法始终是显式判空：
if err != nil {
return fmt.Errorf("read header failed: %w", err)
}
return nil
errors.Wrap 和 fmt.Errorf("%w") 的底层结构不兼容
errors.Wrap（来自 github.com/pkg/errors）生成的是带堆栈的自定义 struct，而 fmt.Errorf("%w") 生成的是标准库的 *fmt.wrapError。二者都实现 Unwrap()，但行为差异直接影响错误链遍历：
立即学习“go语言免费学习笔记（深入）”；
-
errors.Is()在跨包比较时可能失效：比如用fmt.Errorf("%w")包装后，再用pkg/errors.Cause()取不到原始错误 -
errors.As()对某些第三方错误类型提取失败，因类型断言路径断裂 - 日志打印时：
%+v对fmt.wrapError仅显示包装文本，不输出堆栈；而pkg/errors的%+v才会展开完整调用帧
项目若已大量使用 pkg/errors，不要在部分地方突然切回 %w；新项目建议全程用原生 %w + errors.Is/errors.As，避免混用。
errors.Is() 失效往往是因为错误链被手动拼接中断
errors.Is(err, target) 能工作，前提是整条链上每个节点都正确实现了 Unwrap() error 方法，并且没有中间层返回 nil 或丢弃原始错误。
典型断裂点：
- 用
fmt.Errorf("failed: %v", err)替代%w：这只是一个字符串格式化，不构成包装 - 手写错误 struct 但没实现
Unwrap()方法 - 某层包装后，
Unwrap()返回nil（例如自定义 wrapper 在特定条件下不嵌套）
验证方式很简单：
fmt.Printf("unwrapped: %+v\n", errors.Unwrap(err))
// 如果输出 nil 或非预期错误，说明链在此处断了
性能敏感场景下，包装深度应控制在 4 层以内
每层 %w 或 Wrap 都带来额外内存分配和接口动态调度开销。实测表明，当错误链深度 ≥ 5 层时，errors.Is() 平均耗时上升约 40%，errors.As() 提取失败率也明显增加（尤其在并发高频错误路径中）。
建议策略：
- 只在真正需要新增语义上下文的地方包装（如 “failed to parse config” → “failed to start service”）
- 避免在循环内、日志装饰器、中间件拦截器等高频路径中无差别包装
- 调试期可临时加多层，上线前用
fmt.Printf("%+v", err)检查实际链长，裁剪冗余层
最易被忽略的一点：错误包装不是越多越好，而是要在可追溯性与运行时成本之间做显式权衡——尤其当你的服务每秒处理数万请求时，每一层包装都在悄悄吃掉可观的 CPU 时间。
