Golangfmt包错误输出实用技巧

本文深入剖析了 Go 语言中使用 fmt 包正确打印错误的关键技巧与常见误区：强调 %+v 是唯一能有效展开错误链（如 %w 包装的嵌套错误）的格式动词，但其效果高度依赖错误类型是否实现了 fmt.Formatter 接口（标准库 fmt.Errorf 不支持调用栈展开，而 github.com/pkg/errors 等第三方库则可提供文件行号等调试信息）；%v 仅显示顶层 Error() 结果，%s 则强制且保守地调用 Error() 方法；更重要的是，必须始终先判断 err != nil 再打印，避免空错误干扰日志可读性，并推荐在生产中优先使用 log.Printf 而非裸 fmt，让开发者真正掌握格式化背后的接口机制，告别“failed: %v”式无效日志。

直接用 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），调试时推荐，但生产日志慎用——可能暴露敏感路径或内部结构

示例：

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) // 输出相同（标准库 <code>fmt.Errorf</code> 不实现 %q 展开），但若用 <code>github.com/pkg/errors</code>，此处会多出文件行号

打印错误时漏掉 err != nil 检查是最大陷阱

很多人写成：

data, err := ioutil.ReadFile("config.json")
fmt.Println(err) // 即使 err == nil，也会打印 <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 的支持很有限，别指望它自动打出调用栈。

终于介绍完啦！小伙伴们，这篇关于《Golangfmt包错误输出实用技巧》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！