%w仅嵌套错误而不拼接字符串，外层文本需通过fmt.Sprint或日志%v格式化才显示；必须用%w才能保留errors.Is/As判定能力，且要求参数为error类型，否则panic。
fmt.Errorf 用 %w 包装错误时，为什么原错误信息消失了？
因为 %w 只负责嵌套错误，不自动拼接字符串。如果你写 fmt.Errorf("failed to open file: %w", err)，输出的错误文本里确实只显示 err.Error() 的内容，前面那句 "failed to open file: " 看似没生效——其实它生效了，只是被底层错误的 Error() 方法覆盖了显示逻辑。
Go 的错误链（error chain）默认只展示最外层错误的 Error() 返回值，但你可以用 errors.Unwrap() 或 errors.Is()/errors.As() 向下查。
- 真正要“看到上下文文字”，得靠
fmt.Errorf("xxx: %w", err)中的xxx:部分参与最终错误格式化——它会在调用fmt.Sprint(err)或日志打印时出现，前提是该错误没被其他包装层吞掉 - 如果用
log.Printf("%v", err)，会显示完整链；但用log.Printf("%s", err)就只取最内层的.Error() - 别在包装时混用
%v和%w：比如fmt.Errorf("read %v: %w", path, err)是错的——%v会触发path.String()（如果实现了），而你大概率只想打印路径字符串，应该用%s
什么时候必须用 %w，而不是 %s 或 %v？
只有当你需要保留错误可判定性（比如用 errors.Is() 找特定错误类型，或用 errors.As() 提取原始错误值）时，%w 才不可替代。
比如 HTTP 客户端返回 net.OpError，你包装成 fmt.Errorf("calling API: %w", err)，上层还能用 errors.As(err, &net.OpError{}) 捕获；但如果写成 fmt.Errorf("calling API: %s", err)，原始类型就彻底丢失了。
立即学习“go语言免费学习笔记（深入）”；
-
%w要求第二个参数是error类型，传非 error 会 panic -
%s和%v会调用.Error()或.String()，结果是纯字符串，无法回溯 - 一个错误链里可以有多个
%w，但只能有一个“最内层”原始错误；中间层包装都算“上下文添加”，不是类型替换
errors.Wrap（来自 github.com/pkg/errors）和 fmt.Errorf + %w 有什么实质区别？
没有运行时区别——github.com/pkg/errors 的 Wrap 在 Go 1.13+ 已被标准库 fmt.Errorf(...%w) 全面取代。它的核心能力（嵌套、判定、提取）现在都由 errors 包原生支持。
唯一遗留价值是 Wrap 自带栈帧捕获（Wrapf 也一样），而标准库不记录堆栈。如果你依赖栈信息做调试，得自己加，或者用 github.com/go-errors/errors 这类扩展包。
- 标准库不提供
WithStack或自动栈捕获，这是明确的设计取舍 -
fmt.Errorf("xxx: %w", err)和errors.Wrap(err, "xxx")在错误判定（Is/As）行为上完全一致 - 项目如果还在用
pkg/errors，升级到标准库只需把errors.Wrap替换为fmt.Errorf("...: %w", ...)，其余逻辑不动
包装错误时最容易被忽略的兼容性细节
Go 1.13 引入错误链后，%w 才可用；低于这个版本的代码不能编译。但更隐蔽的问题是：某些老库（比如旧版 sqlx、gorilla/mux）返回的错误本身不支持 Unwrap()，你用 %w 包一层也没用——链在第一环就断了。
- 检查上游错误是否实现了
interface{ Unwrap() error }，最简单方式是errors.Unwrap(err) != nil - 如果上游错误是字符串错误（如
errors.New("xxx")），它支持Unwrap()（返回 nil），所以链是通的；但自定义结构体错误若没实现Unwrap方法，就会截断 - 跨服务传递错误（比如 gRPC、HTTP 响应）时，
%w包装的上下文在序列化后基本丢失——这时候上下文得靠字段（如 error code、message 字段）显式携带，而非依赖 Go 错误链
