Go 1.13起错误包装应使用fmt.Errorf的%w动词及errors.Is/As/Unwrap，禁用%s/%v拼接或手动Unwrap；%w仅支持单个非nil error，链断裂将导致Is/As失效，调试推荐%+v（Go1.20+）或结构化日志。
error wrap 是 Go 1.13 引入的核心机制，不是第三方库
Go 原生 errors.Wrap 并不存在 —— 那是 github.com/pkg/errors 的旧用法。标准库从 Go 1.13 起提供 fmt.Errorf 的 %w 动词和 errors.Is/errors.As/errors.Unwrap，这才是现代 Go 错误包装链的唯一推荐路径。
直接用 %w 包装错误，才能被标准库函数识别和遍历；用 fmt.Sprintf 拼接字符串、或手动实现 Unwrap() 方法但不返回底层 error，都会断掉追踪链。
-
%w只能出现在fmt.Errorf的格式字符串中，且只能对应一个error类型参数 - 多个错误不能同时用
%w：写成fmt.Errorf("a: %w, b: %w", errA, errB)会编译失败 - 被包装的 error 必须非 nil；传入 nil 会导致
fmt.Errorf返回 nil，意外吞掉错误
如何正确构建可追踪的错误链
关键在于每一层都用 fmt.Errorf + %w 显式传递原始 error，并保持上下文语义清晰。不要在中间层“消化”错误再转成新 error（比如只返回 fmt.Errorf("failed to read file")），否则链就断了。
func readFile(path string) error {
data, err := os.ReadFile(path)
if err != nil {
return fmt.Errorf("read config file %q: %w", path, err) // ← 正确：保留 err
}
return parseConfig(data)
}
func parseConfig(data []byte) error {
if len(data) == 0 {
return fmt.Errorf("config is empty: %w", errors.New("no content")) // ← 可包装自定义 error
}
// ...
return nil
}
调用侧可用 errors.Is 判断是否含特定底层错误（如 os.IsNotExist），或用 errors.As 提取原始 error 实例进行类型断言。
立即学习“go语言免费学习笔记（深入）”；
为什么 errors.Is 和 errors.As 有时不生效
常见原因不是函数用错，而是错误链本身没建好：
- 某一层用了
fmt.Errorf("xxx: %v", err)（%v）而非%w→ 链断裂，errors.Is查不到原始 error - 错误被多次包装但某次漏了
%w，例如：fmt.Errorf("retry #%d: %s", n, err.Error())→ 字符串化后原始 error 丢失 - 用
errors.New或fmt.Errorf（无%w）创建新 error 后，又试图用errors.As断言它为某个自定义类型 → 不可能成功，因为没包装关系
验证链是否完整，可用 errors.Unwrap 手动展开一层，或打印 fmt.Printf("%+v", err)（需配合 github.com/pkg/errors 的 %+v 支持；标准库 %+v 在 Go 1.20+ 才支持简单栈信息，但不显示完整链）。
日志与调试时如何看到完整错误链和调用位置
标准库 fmt.Printf("%+v", err) 在 Go 1.20+ 中对包装 error 会输出类似：
read config file "config.yaml": open config.yaml: no such file or directory
main.readFile
/app/main.go:12
main.loadConfig
/app/main.go:8
但这依赖 error 实现了 Formatter 接口（标准库自动提供），且仅显示最外层和直接包装者的位置。更可靠的调试方式是结合 debug.PrintStack() 或在出错点加断点，或使用结构化日志库（如 zap）的 With(zap.Error(err))，它会递归展开包装链并记录各层消息与栈。
注意：生产环境避免依赖 %+v 输出做自动化解析——它的格式不承诺稳定；应始终以 errors.Is/errors.As 为逻辑判断依据，而非字符串匹配或格式解析。
