Golangfmt包错误输出技巧分享

本文深入解析了 Go 语言中使用 `fmt` 包正确打印错误的关键技巧：强调 `%+v` 是唯一能展开错误链（如 `fmt.Errorf` 包装的底层错误）的格式动词，但其效果高度依赖错误类型是否实现了 `fmt.Formatter` 接口（标准库 `fmt.Errorf` 对 `%+v` 支持有限，而 `github.com/pkg/errors` 等第三方库则可输出文件行号等调试信息）；对比 `%v`（仅调用 `Error()` 显示顶层消息）和 `%s`（强制且仅调用 `Error()`，最安全简洁）的适用场景，并一再警示——漏掉 `err != nil` 判断直接打印错误是高频陷阱，会导致空行刷屏、日志混乱，真正健壮的做法是在非 nil 时才用合适动词输出，并优先选用带上下文的 `log.Printf` 而非裸 `fmt.Println`。

直接用 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) // 输出相同（标准库 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 的支持很有限，别指望它自动打出调用栈。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。