log.printf 支持格式化字符串（如%v），确保单行输出；log.println 自动加空格换行但不支持格式动词，err含换行符时易错行。
log.Printf 和 log.Println 有什么实际区别
主要区别在参数处理和格式控制：log.Printf 支持格式化字符串（类似 fmt.Printf），而 log.Println 自动加空格、换行，不支持格式动词。
常见误用是拿 log.Println 拼接错误信息，比如 log.Println("failed:", err) —— 看似没问题，但一旦 err.Error() 包含换行符，日志就错行；而 log.Printf("failed: %v", err) 能确保单行输出。
-
log.Printf更适合结构化日志片段，尤其要嵌入变量值时 -
log.Println适合快速调试打印，但上线前建议统一换成log.Printf - 两者默认都带时间戳（
log.Ldate | log.Ltime），但不会自动加文件名或行号
如何让 log 输出包含文件名和行号
标准库 log 支持通过 log.SetFlags 启用源码位置标记，但必须搭配 log.Output 或自定义调用方式，因为 log.Printf 和 log.Println 默认不触发 Lshortfile。
正确做法是封装一个辅助函数，调用 log.Output 并传入 2（跳过当前函数和上层包装）：
立即学习“go语言免费学习笔记（深入）”；
func Debug(v ...interface{}) { log.Output(2, fmt.Sprint(v...)) } // 使用前设置标志 log.SetFlags(log.LstdFlags | log.Lshortfile)-
log.Lshortfile显示file.go:23，log.Llongfile显示完整路径 - 不要设
log.Lshortfile却继续用log.Printf—— 它不会生效 - 频繁调用
log.Output有轻微性能开销（需运行时获取调用栈），开发/测试环境够用，高频服务建议用第三方库如zap
log.SetOutput(os.Stdout) 之后为什么还是输出到 stderr
Go 的 log 默认输出到 os.Stderr，但很多人改了 SetOutput 却发现日志仍出现在终端错误流里——通常是因为其他地方（比如测试框架、ide 运行器、容器环境）把 stderr 和 stdout 合并显示了，不是代码没生效。
验证是否真正生效的方法是重定向到文件：
f, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644) log.SetOutput(f) log.Println("test") // 这行会写入 app.log，而不是终端- 如果写入文件成功，说明
SetOutput工作正常 - 容器中常把
stdout当日志主通道，所以建议始终设为os.Stdout，方便日志采集（如 docker、K8s） - 别用
os.Stderr做业务日志输出，容易和真实错误混在一起，排查困难
能否在不引入第三方库的前提下支持日志级别（debug/info/warn/error）
标准库 log 本身没有级别概念，但可以用多个独立的 *log.Logger 实例模拟，每个实例带不同前缀和输出目标（甚至不同 io.Writer）。
例如：
var ( InfoLogger = log.New(os.Stdout, "[INFO] ", log.LstdFlags|log.Lshortfile) ErrorLogger = log.New(os.Stderr, "[ERROR] ", log.LstdFlags|log.Lshortfile) ) InfoLogger.Println("service started") ErrorLogger.Printf("failed to connect: %v", err)- 前缀字符串（如
"[INFO] "）是唯一区分方式，不能靠函数名自动识别级别 - 无法全局开关某级别（比如关掉 debug 日志），得自己加布尔变量控制是否调用
- 如果需要动态调整级别或结构化字段（如 trace_id、user_id），标准库做不到，这时候该考虑
zerolog或zap了
标准库够轻、够稳，但“级别”“上下文”“异步写入”这些现代日志需求，它只提供砖头，不提供图纸。真要上线长期运行的服务，别卡在封装 log 上反复造轮子。