17370845950

log.Printf 比 fmt.Printf 更适合记录错误，因其默认带时间戳、支持输出到文件或自定义 Writer，且可配合 %+v 显示完整错误链和行号，而 fmt.Printf 仅标准输出、无日志上下文、格式不统一。

log.Printf 为什么比 fmt.Printf 更适合记录错误

因为 log.Printf 默认带时间戳、支持输出到文件或自定义 Writer，而 fmt.Printf 只是标准输出，没有日志上下文。直接用 fmt.Printf 打印错误，在服务长期运行时会丢失时间信息、无法区分 error/info 级别、也不方便后续采集。

• log.Printf 输出格式默认为 "2025/01/01 12:00:00 message\n"，fmt.Printf 没有前缀
• 调用 log.SetOutput(os.Stderr) 或 log.SetOutput(f) 可重定向到文件，fmt 需手动处理 os.File
• log.Fatal / log.Panic 会在打印后终止程序，适合不可恢复的初始化错误

如何用 log 包输出带堆栈的错误（非 panic 场景）

Go 标准 log 包本身不自动捕获堆栈，但你可以手动把 debug.PrintStack() 或 runtime/debug.Stack() 的结果拼进去。注意：后者返回 []byte，需转 string；前者直接打印到 os.Stderr，不适合写入日志文件。

import (
    "log"
    "runtime/debug"
)

func handleRequest() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("panic recovered: %v, stack:\n%s", r, string(debug.Stack()))
        }
    }()
    // ...业务逻辑
}

• 仅在 recover() 中用 debug.Stack() 是安全的；在普通错误分支中调用它不会返回当前错误位置的堆栈
• 若只想记录当前行号和文件，用 log.Printf("%s:%d %v", filepath.Base(file), line, err)，配合 runtime.Caller(1)
• 第三方库如 github.com/pkg/errors 或 go.uber.org/zap 更适合结构化错误追踪

fmt.Errorf + log.Printf 组合是否足够健壮

不够。单纯用 fmt.Errorf("failed to read %s: %w", path, err) 再传给 log.Printf，只会输出错误文本，丢失原始错误类型和链路。要保留错误上下文，应优先用 log.Printf("error: %+v", err)（%+v 是关键），它能展开 github.com/pkg/errors 或 Go 1.13+ 的 wrapped error。

• %v 只显示最外层错误消息；%+v 显示完整错误链 + 文件行号（对支持的 error 类型）
• fmt.Errorf("context: %w", err) 中的 %w 必须是最后一个参数，且只允许一个
• 如果 err 是 nil，%+v 输出 ，不会 panic

生产环境该不该混用 log 和 fmt 输出错误

不该。混用会导致日志格式不统一、时间戳缺失、级别混乱（比如 fmt.Println("ERROR: ...") 和 log.Printf 时间不同步），给 ELK 或 Loki 做字段解析带来麻烦。

• 所有错误路径统一走 log.Printf / log.Printf("[ERROR] %v", err)
• 调试时临时用 fmt.Printf 可以，但上线前必须删掉或替换
• 若需多级别（DEBUG/INFO/WARN/ERROR），不要自己封装 fmt，改用 log.SetPrefix 或升级到 zap/zerolog

真正难的是错误分类和可检索性——比如同一个 io.EOF 在 HTTP handler 和数据库连接池里语义完全不同，光靠 log.Printf 无法区分，得靠结构化字段或分通道日志。