如何使用Golang处理日志输出错误_Golang日志记录与异常管理

log.Printf 在 panic 后不输出是因为 panic 未 recover 时后续代码不执行;若已执行但无输出,可能是输出被设为 io.Discard、文件不可写或日志内容为 nil。

为什么 log.Printf 在 panic 后不输出?

Go 的 log 包默认写入 os.Stderr,但若程序在调用 log.Printf 前已触发 panic 且未 recover,后续日志语句根本不会执行。更隐蔽的情况是:你写了日志,但没看到输出——可能因为 log.SetOutput 被意外设为 ioutil.Discard(旧版)或 io.Discard(Go 1.16+),或者日志被重定向到文件但文件路径不可写。

  • 检查是否在 init() 或主流程早期调用了 log.SetOutput(io.Discard)
  • 确认 log.Output 调用的第 2 个参数(即日志内容)不是 nil,否则会静默失败
  • 若重定向到文件,用 os.OpenFile 时加上 os.O_CREATE | os.O_APPEND,并检查返回 error

如何让错误日志自动包含文件名和行号?

log 包本身不自动注入位置信息,需手动启用标志位。但要注意:log.Lshortfilelog.Llongfile 会轻微拖慢性能(每次调用都做运行时栈解析),线上高频日志建议关闭。

log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("something went wrong") // 输出类似:2025/04/05 10:23:41 main.go:12: something went wrong
  • log.Lshortfile 显示 file:linelog.Llongfile 显示完整路径
  • 若用自定义 logger(如 log.New),必须显式传入 flags,例如:log.New(os.Stdout, "", log.LstdFlags|log.Lshortfile)
  • 第三方库如 zapzerolog 默认不带行号,需通过 Caller()With().Caller() 显式开启

recover 捕获 panic 后怎么记录原始错误堆栈?

直接用 log.Println(r) 只能打出 panic 值(比如 "runtime error: index out of range"),丢失调用链。要用 debug.PrintStack()runtime.Stack() 手动捕获。

defer func() {
    if r := recover(); r != nil {
        log.Printf("PANIC: %v", r)
        log.Printf("Stack trace:\n%s", debug.Stack())
    }
}()
  • debug.Stack() 返回 []byte,需转 string;它比 runtime.Stack(buf, false) 更简洁
  • 避免在 defer 中直接调用 log.Fatal,否则会再次 panic,导致进程提前退出,堆栈来不及刷出
  • 若用 zap,推荐 logger.Panic("msg", zap.Any("err", r), zap.String("stack", string(debug.Stack())))

生产环境该不该用标准 log 包?

可以,但仅限低频、非关键服务。标准包没有结构化输出、无日志等级动态控制、不支持异步写入,高并发下 log.Printf 是同步阻塞的,可能拖慢主逻辑。

立即学习“go语言免费学习笔记(深入)”;

  • 日志量大时,log 的锁竞争会导致 goroutine 等待,可用 zap.L().Sugar() 替代,性能高一个数量级
  • 需要按 level 过滤(如只保留 ERROR)?标准包做不到,得自己封装或换库
  • 如果只是调试本地小工具,log 完全够用;但一旦涉及 HTTP 服务、定时任务、微服务间调用,建议从第一天就用 zerologzap

最常被忽略的一点:无论用哪个库,所有日志语句里的变量都要提前评估好是否可能 panic —— 比如 log.Info("user", zap.String("name", user.Name())),如果 user 是 nil,这行本身就会 panic,日志永远发不出去。