如何在Golang中使用日志记录错误信息_Golang日志记录与错误追踪

log.printf 仅输出日志，程序继续执行；log.fatal 输出日志后调用 os.exit(1) 终止进程，仅应用于初始化失败等不可恢复场景。

log.Printf 和 log.Fatal 有什么关键区别

区别在于程序是否继续执行：log.Printf 只输出日志，之后代码照常运行；log.Fatal 输出日志后会调用 os.Exit(1)，直接终止进程。错误处理中误用 log.Fatal 是常见问题——比如在 http handler 里记录一个参数解析失败就退出整个服务，显然不合理。

实际建议：

• 仅在初始化失败（如配置加载、端口绑定）等真正无法继续运行时用 log.Fatal
• 业务逻辑中的错误一律用 log.Printf 或更明确的 log.Println，并配合 return 显式退出当前函数
• 若需带堆栈，log.Printf 不自带，得手动加 debug.PrintStack() 或换用第三方库

为什么 Errors.Wrap 后的日志看不出原始错误位置

errors.Wrap（来自 github.com/pkg/errors）能附加上下文，但默认日志输出不显示堆栈。你写 log.Printf("failed: %v", err)，只打印错误消息，不触发堆栈格式化。

正确做法是用 %+v 动词：

立即学习“go语言免费学习笔记（深入）”；

err := errors.Wrap(io.EOF, "reading header") log.Printf("error: %+v", err) // 才会打印完整堆栈

注意：%+v 是 github.com/pkg/errors 特有的行为，标准库 errors（go 1.13+）不支持。如果混用 fmt.Errorf("...: %w", err)，仍需靠 %+v 配合该包才能看到帧信息。

log.SetOutput(os.Stderr) 还需要设置吗

默认就是 os.Stderr，所以绝大多数情况不用显式设置。但容易被忽略的是：一旦你调用了 log.SetOutput 指向文件或缓冲区，后续所有 log.Printf 都会写入那里——包括第三方库内部用的 log 包（比如 net/http 的某些调试日志）。

如果你只是想分离“应用错误日志”和“标准输出”，更安全的做法是：

• 不要动全局 log 实例，改用自定义 logger：log.New(file, "[ERROR] ", log.LstdFlags)
• 避免依赖 log.SetOutput，尤其在库代码中——它有副作用，影响其他模块
• 若必须重定向，确保在 main() 最早处设置，且不被子包覆盖

zap.Logger 里 Errorw 和 Error 传参方式为何不同

zap.Errorw 是 zap 提供的结构化日志快捷方法，本质是 Error + With 的组合，但它的参数顺序和语义固定：msg 必须是第一个字符串，后面必须是键值对（偶数个参数）。

logger.Errorw("db query failed", "sql", sql, "err", err) // ✅ 正确 logger.Error("db query failed", err)                      // ❌ 编译失败：Error 只接受 msg string

真正对应标准库 log.Printf 行为的是 logger.Warnf 或 logger.Errorf，它们支持格式化字符串。而 logger.Error 只接收一个 error 类型参数，用于自动提取堆栈和字段，不能传字符串消息。

容易踩的坑：

• 把 logger.Errorw("msg", err) 写成两个参数，漏掉键名，导致日志字段错位
• 误以为 Errorw 能自动展开 err 的堆栈——其实要额外加 zap.Error(err) 字段才完整
• 在高并发场景下频繁调用 Errorw 传大量字符串，产生不必要的内存分配

golang 错误日志真正的复杂点不在语法，而在错误链的传播路径和日志上下文的生命周期管理——比如一个 HTTP 请求经过中间件、service、dao 多层包装，最终出错时，你得确保关键字段（request_id、user_id）能透传到最后一行日志里，而不是只靠 fmt.Sprintf 拼接。