Golang日志记录错误技巧分享

在Golang实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《Golang日志记录错误方法详解》，聊聊，希望可以帮助到正在努力赚钱的你。

错误信息被截断因log.Printf默认不展开error结构，仅调用Error()方法；应使用%+v并配合Go 1.13+ errors包或pkg/errors库，或显式递归Unwrap；开启log.Lshortfile可显示文件行号，但需注意封装干扰；log.Fatal可能丢日志因os.Exit不刷新缓冲区，推荐先log再os.Exit。

log.Printf 和 error 一起用时，为什么错误信息总被截断？

因为 log.Printf 默认不展开 error 类型的底层结构，直接传入 err 只会调用其 Error() 方法返回字符串，丢失堆栈、嵌套错误等上下文。尤其在用 fmt.Errorf("failed: %w", err) 包装后，单纯 log.Printf("%v", err) 无法显示原始错误链。

• 正确做法是用 %+v 格式符（需配合支持错误展开的库，如 github.com/pkg/errors 或 Go 1.13+ 的 errors.As/errors.Unwrap）
• 更推荐：统一用 log.Printf("failed to do X: %+v", err) + 启用 -gcflags="all=-l" 避免内联干扰堆栈捕获（仅调试期）
• 生产环境别依赖 %+v，改用显式提取：先判断是否实现了 interface{ Unwrap() error }，再递归打印

如何让 log 输出包含文件名和行号？

标准库 log 支持通过 log.SetFlags() 开启位置标记，但默认关闭。开启后，每条日志开头会追加 file:line，对定位错误源头非常关键。

log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("something happened") // 输出类似：2024/04/05 10:23:41 main.go:12: something happened

• log.Lshortfile 显示相对路径（如 main.go:12），log.Llongfile 显示绝对路径
• 注意：log.Lshortfile 在跨包调用时可能指向日志封装函数而非真实出错位置，此时应避免二次封装 log.Printf，或改用 runtime.Caller 手动获取
• 如果用了 log.New 自定义 logger，必须对每个实例单独调用 SetFlags

error 能否直接塞进 log.Printf 的格式化参数而不转成字符串？

可以，但要区分场景：

• 纯值传递没问题：log.Printf("connect failed: %v", err) —— 这里 err 是接口类型，log 内部会调用 err.Error()
• 若想保留错误类型用于后续判断（比如重试逻辑），不要提前转成 err.Error()，否则丢失类型信息和可比性
• 切忌这样写：log.Printf("error: %s", err.Error()) —— 多余且当 err == nil 时 panic
• 更安全的 nil 检查模式：

  if err != nil {
      log.Printf("operation failed: %v", err)
      return err
  }

为什么用 log.Fatal(err) 后程序没输出就退出了？

log.Fatal 内部调用 os.Exit(1)，它不等待 stdout 缓冲区刷新，导致最后几条日志（尤其是刚写入还没 flush 的）丢失。常见于容器环境或重定向到文件时。

• 解决方法一：手动 flush：

  log.SetOutput(os.Stderr) // 确保输出到 stderr
  log.SetFlags(log.LstdFlags | log.Lshortfile)
  log.Fatal(err) // 仍可能丢，不推荐

• 解决方法二（推荐）：拆成两步 —— 先 log，再 os.Exit：

  if err != nil {
      log.Printf("fatal error: %+v", err)
      os.Exit(1)
  }

• 根本规避方式：不用 log.Fatal，改用返回错误 + 主函数统一处理，符合 Go 错误处理惯用法

以上就是《Golang日志记录错误技巧分享》的详细内容，更多关于的资料请关注golang学习网公众号！