何时选择 log 而非 fmt 进行调试与错误输出？-Golang-PHP中文网

何时选择 log 而非 fmt 进行调试与错误输出？

在 Go 中，log 适用于需时间戳、日志级别、可重定向输出的生产环境调试与错误记录；fmt 更适合快速开发阶段的临时变量打印。二者输出目标（stderr vs stdout）、元信息支持和可配置性存在本质差异。

在 go 中，`log` 适用于需时间戳、日志级别、可重定向输出的生产环境调试与错误记录；`fmt` 更适合快速开发阶段的临时变量打印。二者输出目标（stderr vs stdout）、元信息支持和可配置性存在本质差异。

Go 提供了 fmt 和 log 两个标准库用于输出信息，但它们的设计目标与适用场景截然不同。理解其差异是写出可维护、可观察、符合工程规范代码的关键。

✅ 何时优先使用 `log`

错误记录必须用 log：错误信息属于系统可观测性的一部分，应默认输出到 stderr（而非 stdout），便于与正常业务输出分离，并兼容日志收集工具（如 systemd、rsyslog、Fluentd）。
需要结构化上下文：log 默认添加时间戳（如 2024/05/20 14:22:36），可通过 log.SetFlags() 启用 log.Lshortfile 或 log.Llongfile 显示调用位置，极大提升问题定位效率：
```
log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("failed to connect") // 输出：2024/05/20 14:22:36 main.go:42: failed to connect
```

支持运行时重定向：可统一将所有日志写入文件、网络端点或自定义 Writer：

f, _ := os.OpenFile("app.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
log.SetOutput(f)
defer f.Close()

⚠️ `fmt` 的适用边界

仅限开发调试：fmt.Printf / fmt.Println 输出至 stdout，适合快速验证逻辑、打印中间变量（如 fmt.Printf("DEBUG: h=%v\n", h)），但绝不应出现在生产代码的错误处理路径中。
注意并发安全陷阱：虽然 fmt.Printf 是 goroutine-safe，但当输出内容超过 OS 缓冲区（通常 4KB）时，多 goroutine 并发调用可能导致日志行被截断或乱序（如 "err=EOF" 和 "at line 123" 混在一起）。而 log 内部加锁确保整条日志原子写入。

? 常见反模式与改进建议

// ❌ 错误：混淆输出通道，丢失上下文，不可重定向
if err != nil {
    fmt.Printf("ERROR: %v\n", err) // 写入 stdout，难以过滤
    return err
}

// ✅ 正确：语义明确，可审计，可配置
if err != nil {
    log.Printf("database query failed: %v", err) // 自动带时间戳，stderr
    return err
}