log.Printf支持格式化输出，log.Println仅空格拼接；SetFlags可添加时间戳和行号；Fatal/Panic在HTTP handler中禁用，避免进程退出；SetOutput可切换输出目标且线程安全。
log.Printf 和 log.Println 有什么实际区别？
主要区别在参数处理和格式控制：log.Printf 支持格式化字符串（类似 fmt.Printf），而 log.Println 只做简单空格拼接，不支持占位符。
常见误用是把带变量的日志硬塞进 log.Println，结果输出一串地址或类型名——比如 log.Println("user:", user) 中 user 是结构体，会打印其内存表示，而非字段内容。
-
log.Printf("user id=%d, name=%s", user.ID, user.Name)—— 正确，可控、可读 -
log.Println("user id=", user.ID, "name=", user.Name)—— 可行但冗长，且无法对齐或加前缀 - 避免
log.Println("error:", err.Error())，直接用log.Printf("error: %v", err)
如何让 log 输出带时间戳和文件行号？
标准 log 包默认不带这些信息，需通过 log.SetFlags 启用。关键标志位有：log.LstdFlags（日期+时间）、log.Lshortfile（文件名:行号）、log.Lmicroseconds（微秒级时间）。
注意：log.Lshortfile 会降低性能（需运行时解析调用栈），生产环境慎用；调试阶段建议组合使用：
立即学习“go语言免费学习笔记（深入）”；
log.SetFlags(log.LstdFlags | log.Lshortfile | log.Lmicroseconds)
log.Printf("request processed") // 输出类似：2024/05/22 14:23:11.123456 handler.go:42: request processed
- 不要用
log.Llongfile，路径太长且无必要 - 如果已用
log.SetOutput重定向到文件，SetFlags仍生效 - 多个 goroutine 共享同一
*log.Logger是安全的
为什么不能直接用 log.Fatal 结束 HTTP handler？
log.Fatal 内部会调用 os.Exit(1)，导致整个进程退出——这对 Web 服务是灾难性的，一次错误请求就让所有连接中断。
HTTP handler 中应只记录错误并返回响应，例如：
func handler(w http.ResponseWriter, r *http.Request) {
if err := doSomething(); err != nil {
log.Printf("handler failed: %v", err) // 记录，但不退出进程
http.Error(w, "internal error", http.StatusInternalServerError)
return
}
// ...
}
-
log.Panic同样危险，它触发 panic，可能被上层 recover，但不可靠 - 真正该用
log.Fatal的场景极少：main 函数初始化失败（如无法绑定端口、加载配置失败） - 若需终止当前请求上下文，用
return或http.Error即可
log.SetOutput 能否切换到不同文件或 stdout/stderr？
可以，而且非常常用。只要传入实现了 io.Writer 接口的对象即可，比如 os.Stdout、os.Stderr、os.File，甚至自定义的带缓冲或轮转的 writer。
典型做法是按环境区分输出目标：
if os.Getenv("ENV") == "prod" {
f, _ := os.OpenFile("/var/log/myapp.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
log.SetOutput(f)
} else {
log.SetOutput(os.Stdout)
}
- 切换
log.SetOutput是线程安全的，但频繁切换可能引发竞态（比如两个 goroutine 同时调用） - 如果写入文件，记得在程序退出前
f.Close()，否则日志可能丢失 -
标准库不支持日志轮转，需要借助第三方包（如
lumberjack）或自行封装
log.Lshortfile 查 bug，先确保每条日志都有明确上下文（比如请求 ID、用户 ID），再考虑加行号。 
