log.Printf 比 fmt.Printf 更适合记录错误，因其默认带时间戳、支持输出到文件或自定义 Writer，且可配合 %+v 显示完整错误链和行号，而 fmt.Printf 仅标准输出、无日志上下文、格式不统一。
log.Printf 为什么比 fmt.Printf 更适合记录错误
因为 log.Printf 默认带时间戳、支持输出到文件或自定义 Writer，而 fmt.Printf 只是标准输出，没有日志上下文。直接用 fmt.Printf 打印错误，在服务长期运行时会丢失时间信息、无法区分 error/info 级别、也不方便后续采集。
-
log.Printf输出格式默认为"2024/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输出
生产环境该不该混用 log 和 fmt 输出错误
不该。混用会导致日志格式不统一、时间戳缺失、级别混乱（比如 fmt.Println("ERROR: ...") 和 log.Printf 时间不同步），给 ELK 或 Loki 做字段解析带来麻烦。
立即学习“go语言免费学习笔记（深入）”；
- 所有错误路径统一走
log.Printf/log.Printf("[ERROR] %v", err) - 调试时临时用
fmt.Printf可以，但上线前必须删掉或替换 - 若需多级别（DEBUG/INFO/WARN/ERROR），不要自己封装
fmt，改用log.SetPrefix或升级到zap/zerolog
真正难的是错误分类和可检索性——比如同一个 io.EOF 在 HTTP handler 和数据库连接池里语义完全不同，光靠 log.Printf 无法区分，得靠结构化字段或分通道日志。
