Go 1.13+ 用 %w 包装错误可保留堆栈和类型，支持 errors.Is/As；需避免 %v 拼接、换行，自定义错误须实现 Unwrap 方法，日志应直接传 error 而非 Error() 字符串。
Go 1.13+ 的 fmt.Errorf 包装语法怎么用才不丢堆栈？
直接用 fmt.Errorf("failed to open file: %w", err) 是最简包装方式，但必须用 %w（不是 %v 或 %s），否则底层错误被转成字符串，errors.Is/errors.As 就查不到原始错误了。
常见错误现象：调用 errors.Is(err, fs.ErrNotExist) 返回 false，明明底层是文件不存在——大概率是中间某层用了 %v 或拼接字符串。
-
%w只能出现在格式字符串末尾，且仅支持一个（Go 1.22 开始允许多个，但需明确标注） - 若需多层上下文，应逐层包装：
fmt.Errorf("processing item %s: %w", id, innerErr) - 不要在包装时加换行或多余空格，
fmt.Errorf("failed:\n%w", err)会让err.Error()输出带换行，某些日志系统会截断
如何安全地从包装链中提取原始错误或特定类型？
别用 err.Error() 做字符串匹配——脆弱、不可靠、丢失类型信息。应该用 Go 标准库的解包能力：
- 判断是否为某类错误：
errors.Is(err, io.EOF)或errors.Is(err, sql.ErrNoRows) - 提取具体错误实例：
var pgErr *pgconn.PgError; if errors.As(err, &pgErr) { ... } - 手动遍历包装链（极少需要）：
for errors.Unwrap(err) != nil { err = errors.Unwrap(err) }，但通常Is/As已足够
注意：errors.As 要求目标指针类型与原始错误类型兼容；如果包装前是值类型（如 os.PathError），而你声明的是 *os.PathError，就会失败——统一用指针接收更稳妥。
自定义错误类型要不要实现 Unwrap 方法？
要，但只在你需要控制解包逻辑时才显式实现。大多数情况下，用 fmt.Errorf("%w", ...) 包装已自动支持标准解包。
如果你写了一个结构体错误类型（比如 type ValidationError struct { Msg string; Code int; Err error }），就必须实现：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func (e *ValidationError) Unwrap() error { return e.Err }
否则 errors.Is 和 errors.As 无法穿透到 e.Err。漏掉这一步是自定义错误最常踩的坑——表面报错正常，但所有上游的错误分类逻辑都失效。
- 不要返回
nil从Unwrap，会导致解包提前终止 - 如果错误可能无底层原因（比如纯业务校验失败），可返回
nil，此时errors.Is仍可匹配该错误自身 - 避免在
Unwrap中做计算或 IO，它可能被高频调用
log/slog 记录包装错误时，怎样避免重复打印或丢失上下文？
直接传 err 给 slog.Error(..., "err", err) 是安全的——slog 内部会调用 fmt.Formatter 接口，正确展开包装链并保留原始错误类型。
但要注意：
- 不要手动调用
err.Error()后再传入日志，那样只剩字符串，丢失所有结构化信息 - 如果用第三方日志库（如
zerolog或logrus），确认它是否支持errors.Unwrap链式解析；不支持的需自行递归提取Unwrap()并打点记录 - 生产环境慎用
fmt.Printf("%+v", err)——虽然它能显示堆栈，但依赖github.com/pkg/errors等旧库，与标准库%w不兼容，混用会导致Is/As失效
错误包装真正的复杂点不在语法，而在团队对 “何时该包装、何时该替换、何时该透传” 缺乏一致约定。同一个错误在三层函数里被包装三次，最后看到的是一长串 “failed to… because failed to… due to…”，但关键定位信息（比如 SQL 状态码或 HTTP 状态）反而被淹没。这时候，比语法更重要的是错误语义的收敛设计。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
