Go 标准库 log 适合调试但不适用于生产环境，需用 SetFlags 和 SetOutput 自定义输出，Printf 比 Print 更常用因支持格式化，Fatal/Panic 会终止进程或触发 panic，不可用于 HTTP 等需错误传播场景。
Go 标准库 log 足够轻量，适合小型工具、CLI 或调试阶段快速打日志，但不支持日志分级、文件轮转、结构化输出等生产需求——别用它直接上线服务。
如何初始化并配置 log 的输出格式和目标
默认的 log 实例输出到 stderr，带时间戳和前缀，但不带文件名/行号。要自定义，需调用 log.SetFlags() 和 log.SetOutput()：
-
log.SetFlags(log.LstdFlags | log.Lshortfile)可同时启用标准时间戳 + 文件名:行号 - 想写入文件？先
f, _ := os.OpenFile("app.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)，再log.SetOutput(f) - 注意：一旦调用
SetOutput()，所有后续log.Print/Printf/Println都会写入该目标，包括第三方库中未重定向的log调用
为什么 log.Printf 比 log.Print 更常用
log.Print 只做字符串拼接，而 log.Printf 支持格式化（类似 fmt.Printf），实际开发中几乎总是需要变量插值：
log.Printf("user %s login failed, attempts: %d", username, attempts)
// 而不是
log.Print("user " + username + " login failed, attempts: " + strconv.Itoa(attempts))
- 格式动词必须与参数类型匹配，否则运行时 panic（如用
%d传入字符串） - 避免在日志里拼接敏感信息（密码、token），应使用占位符而非直接拼入字符串，方便后续脱敏或过滤
为什么不能依赖 log.Fatal 做错误处理
log.Fatal 等价于 log.Print() + os.Exit(1)，它会立即终止进程，无法被 defer 或 recover 捕获：
立即学习“go语言免费学习笔记（深入）”；
- 在 HTTP handler 中误用
log.Fatal会导致整个服务崩溃，而不是仅当前请求失败 - 正确做法是返回 error，由上层决定是否记录 + 终止（比如
main函数中） -
log.Panic同理，会触发 panic，除非你明确需要 panic 链式传播
标准 log 库没有上下文传递能力，也没有字段绑定机制；如果需要 trace ID、用户 ID 等动态字段，要么手动拼进每条日志，要么换用 zap、zerolog 这类结构化日志库——这点常被忽略，直到日志排查时发现找不到关联线索。
