应使用 %+v 展开错误链（需错误类型实现 fmt.Formatter），%v 仅显示顶层消息，%s 强制调用 Error()；打印前须判 err != nil，避免输出 。
直接用 fmt.Println 或 fmt.Printf 打印 error 值，通常只显示错误文本，丢失上下文和底层类型信息；真要调试或记录错误，得用对函数、传对参数，否则日志里全是“failed: %v”这种无效内容。
为什么 fmt.Error 不是标准函数？
Go 里没有 fmt.Error 这个函数——这是常见误解。真正起作用的是 error 接口自带的 Error() 方法，它返回 string；fmt 包只是在格式化时自动调用它（比如用 %v 或 %s）。但注意：%v 对 error 类型默认调用 Error()，而 %+v 在某些错误类型（如 fmt.Errorf 带 %w 包装的）下才会展开堆栈或嵌套错误。
- 普通
errors.New("xxx")：用%v和%+v效果一样，都只输出字符串 -
fmt.Errorf("wrap: %w", err)：只有%+v才会显示被包装的原始错误 - 第三方错误库（如
github.com/pkg/errors）：依赖其自定义fmt.Formatter实现，%+v才有效
fmt.Printf 中该选 %v、%s 还是 %+v？
取决于你要不要错误链和位置信息：
-
%s：强制调用err.Error()，最保守，不触发任何额外行为，适合日志摘要行 -
%v：默认行为，对大多数error和%w包装的也只显示顶层消息 -
%+v：唯一能展开错误链的选项（前提是错误类型实现了fmt.Formatter），调试时推荐，但生产日志慎用——可能暴露敏感路径或内部结构
示例：
立即学习“go语言免费学习笔记（深入）”；
err := fmt.Errorf("db timeout: %w", errors.New("context deadline exceeded"))
fmt.Printf("%%v: %v\n", err) // 输出：db timeout: context deadline exceeded
fmt.Printf("%%+v: %+v\n", err) // 输出相同（标准库 fmt.Errorf 不实现 %q 展开），但若用 github.com/pkg/errors，此处会多出文件行号
打印错误时漏掉 err != nil 检查是最大陷阱
很多人写成：
data, err := ioutil.ReadFile("config.json")
fmt.Println(err) // 即使 err == nil，也会打印 ，干扰日志可读性
正确做法永远先判断：
- 日志中只在
err != nil时输出错误详情，避免 - 用
log.Printf("failed to read config: %v", err)替代裸fmt，更符合生产习惯 - 如果必须用
fmt（比如调试），加 guard：if err != nil { fmt.Printf("ERROR: %v\n", err) }
错误格式化的关键不在函数名有多花哨，而在你是否清楚每个动词（%v/%+v）背后触发了哪个接口方法，以及当前错误类型有没有实现它——标准库的 fmt.Errorf 对 %+v 的支持很有限，别指望它自动打出调用栈。
