直接用 err.error() 即可，它是最标准、轻量且无副作用的方式；需先判空防 panic，避免冗余包装或重复前缀，仅在需错误链支持时才用 fmt.errorf(... %w)。
直接用 err.Error() 就行，别绕弯
Go 的 error 接口只有一个方法：Error() string。只要值不是 nil，调用它就能拿到人类可读的错误描述。这是最标准、最轻量、最无副作用的方式。
常见错误现象：有人试图用 fmt.Sprintf("%s", err) 或 fmt.Sprint(err)，其实底层还是调用了 Error() —— 多此一举，还可能掩盖自定义 Error() 实现的语义（比如带堆栈的 error 包）。
- 所有标准库和主流 error 构造方式（
errors.New、fmt.Errorf、errors.Join等）都实现了该方法 - 如果
err是nil，调用err.Error()会 panic，务必先判空 - 不要在日志里无条件拼接
"failed: " + err.Error()，有些 error 自带前缀（比如os.PathError），重复描述反而啰嗦
fmt.Errorf 套一层再转字符串？没必要
有人为了“更安全”或“统一格式”，习惯性把原始 error 包一层：fmt.Errorf("read config: %w", err)，再调用 .Error()。这在需要保留原始 error 链时合理，但纯转字符串场景下，只是徒增开销和歧义。
使用场景：只有当你需要向上层暴露错误上下文、支持 errors.Is/errors.As 判断，或要打印完整 error 链（如用 %+v）时，才值得包装。
-
fmt.Errorf(... %w)创建的是新 error，.Error()返回的是带前缀的字符串，原始 error 的文本可能被截断或混淆 - 性能上：分配额外对象，GC 压力略升；对高频错误路径（如网络请求失败）有实际影响
- 兼容性：某些老版本 Go（%w，但你如果只用
.Error()，完全不受影响
想打印堆栈？别靠 Error()，用 %+v 或 errors.PrintStack
err.Error() 永远只返回描述文本，不包含文件名、行号或调用栈。想看哪里出的错，得换方式。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见错误现象：把 err.Error() 当成调试信息全量打到日志里，结果线上报错只有一句 “no such file or directory”，根本定位不到哪行代码打开的文件。
- 临时调试：用
fmt.Printf("%+v\n", err)—— 如果 error 实现了fmt.Formatter（如github.com/pkg/errors或 Go 1.17+ 的errors.Join堆栈），会输出栈帧 - 生产环境：推荐用结构化日志库（如
zap）的logger.With(zap.Error(err))，它会自动提取并格式化堆栈 - 注意：
fmt.Printf("%+v", nil)不 panic，但输出<nil></nil>；而nil.Error()会 panic，这点行为不一致容易踩坑
第三方 error 包（如 github.com/pkg/errors）现在基本不用了
Go 1.13 引入了 %w 动词和 errors.Is/errors.As，1.20 又加了 errors.Join，标准库已覆盖绝大多数错误包装与判断需求。继续引入旧包，只会增加依赖、混淆行为、且可能和新特性冲突。
使用场景：仅当项目还在维护 Go 1.12 或更早版本时，才需考虑兼容性。
-
pkg/errors的.Error()行为和标准库一致，但它的.Cause()已被errors.Unwrap()替代 - 混用会导致 error 链断裂：比如用
pkg/errors.Wrap包装后，再用errors.Is(err, os.ErrNotExist)可能返回 false - Go 官方文档明确建议：优先使用标准库
errors和fmt，避免额外抽象
真正要注意的，是别在没检查 err != nil 的前提下就调用 Error()；还有就是别把 Error() 当成调试唯一手段——它只负责“说什么错了”，不说“在哪错的”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
