go 1.13+ 应用 fmt.Errorf 配合 %w 动词嵌套错误以支持 errors.Is/As 查找，避免用 %s 拼接导致错误链断裂；需自定义错误类型并实现 Unwrap() 方法携带结构化字段，且 %+v 可递归打印完整错误链。
Go 1.13+ 如何用 fmt.Errorf 嵌套错误并附加上下文
Go 1.13 引入了错误链（error wrapping）机制，核心是支持 %w 动词。它不是简单拼字符串，而是让错误可被 errors.Is 和 errors.As 向下查找——这才是“带额外信息”的正确姿势。
常见错误是用 fmt.Sprintf 拼接错误消息，导致原始错误丢失、无法判断类型或提取底层错误值。
- ✅ 正确：
return fmt.Errorf("failed to open config file: %w", os.Open(path)) - ❌ 错误：
return fmt.Errorf("failed to open config file: %s", err.Error())（破坏错误链） - ⚠️ 注意：
%w只接受一个error类型参数，不能跟多个或非 error 值
如何在不破坏错误链的前提下添加结构化字段（如 request_id、code）
标准 fmt.Errorf + %w 只能加文本描述和嵌套错误，无法携带结构化元数据。这时需要自定义错误类型，但必须实现 Unwrap() error 方法才能参与错误链。
典型场景：http handler 中希望每个错误都附带当前 request_id 和业务码 code，同时保留原始错误以便重试或分类处理。
立即学习“go语言免费学习笔记（深入）”；
- 定义结构体时嵌入
error字段，并显式实现Unwrap()返回它 - 不要覆盖
Error()方法里把所有字段都转成字符串——这会让日志重复冗余；只放关键标识，详细上下文由日志系统单独采集 - 示例：
type appError struct { Code string RequestID string Err error } func (e *AppError) Error() string { return fmt.Sprintf("[%s] %s", e.Code, e.Err.Error()) } func (e *AppError) Unwrap() error { return e.Err }
为什么不用 errors.WithMessage（github.com/pkg/errors）？
这个第三方包曾广泛使用，但它已被 Go 官方错误链设计事实取代。继续用它会带来两个实际问题：
- 与标准库
errors.Is/As不完全兼容：某些嵌套深度下errors.As找不到目标错误类型 - 构建的错误对象无法被
fmt.Errorf(... %w)正确包裹，容易意外截断错误链 - 新项目应直接使用标准库，老项目迁移只需替换
pkg/errors.WithMessage→fmt.Errorf("%w", ...)，再补上必要文本即可
调试时怎么看到完整错误链和所有附加字段
fmt.Printf("%+v", err) 是关键——仅 %v 或 %s 会忽略包装信息，而 %+v 会递归打印每一层错误及其类型（包括自定义字段，前提是实现了 fmt.Formatter 接口）。
- 如果用了自定义错误类型且想让
%+v显示RequestID等字段，需额外实现fmt.Formatter接口 - 生产环境别依赖
%+v输出到用户端，它含内部结构，可能泄露敏感路径或配置 - 日志采集时建议统一用
errors.Unwrap循环提取最底层错误，再结合runtime.Caller补充位置信息
实际中最容易被忽略的是：**自定义错误类型必须返回非 nil 的 Unwrap() 结果，否则 errors.Is 无法穿透到原始错误**。哪怕只是包装一个字符串，也要确保它最终能链到某个真实 error 实例。