log.Printf支持格式化字符串，log.Println自动加空格和换行但不支持格式动词；前者适合变量插值，后者仅限简单输出；混用会导致日志格式割裂。
log.Printf 和 log.Println 有什么实际区别
主要区别在参数处理和格式控制：log.Printf 支持格式化字符串（类似 fmt.Printf），而 log.Println 自动在参数间加空格、末尾加换行，不支持格式动词。
常见误用是拿 log.Println 拼接错误信息，比如 log.Println("failed:", err) —— 看似简洁，但一旦 err 是 nil，输出变成 failed: ，可读性差；更糟的是，如果后续想加时间戳或级别前缀，log.Println 无法统一拦截修改。
-
log.Printf("connect timeout: %v, retry after %dms", err, delay)—— 推荐用于带变量插值的场景 -
log.Println("server started on :8080")—— 仅限简单、无格式需求的调试输出 - 避免混用：同一项目里不要一部分用
Printf、一部分用Println，日志格式会割裂
如何让 log 输出包含文件名和行号
标准 log 包默认不带位置信息，需通过 log.SetFlags 启用，但要注意它只影响后续输出，且不能动态开关。
关键配置项是 log.Lshortfile 或 log.Llongfile，配合 log.LstdFlags 使用。例如：
立即学习“go语言免费学习笔记（深入）”；
log.SetFlags(log.LstdFlags | log.Lshortfile)
log.Println("hello") // 输出形如：2024/05/10 14:23:01 main.go:12: hello
-
log.Lshortfile显示file:line，log.Llongfile显示完整路径 - 生产环境慎用
log.Lshortfile：每次调用都触发运行时反射获取调用栈，性能损耗明显（尤其高频日志） - 如果需要条件性开启（如 debug 模式），建议封装一层函数，而非反复调用
SetFlags
为什么直接替换 log.SetOutput 有时不生效
常见于想把日志重定向到文件或 io.MultiWriter 时，发现部分日志仍打到终端 —— 很可能因为某些第三方库内部创建了独立的 *log.Logger 实例，没走全局 log 包的默认 logger。
标准 log 包的 log.Printf 等函数，本质是操作一个包级变量 std（类型为 *log.Logger）。但像 http.Server 的日志、database/sql 的驱动日志，往往使用自己 new 出来的 log.Logger，它们的 SetOutput 是独立的。
- 检查是否所有日志入口都覆盖：除了
log.SetOutput，还要确认http.Server.ErrorLog、sql.DB.SetLogger（Go 1.21+）等显式字段 - 不要依赖全局
log包做生产级日志管理；它缺少分级、异步写入、轮转等能力 - 若必须统一，可用
log.New创建自定义 logger，并在各处显式传入，而非依赖包级函数
log 包能否实现 ERROR/WARN/INFO 分级
不能。标准 log 包没有任何内置级别概念，log.Print、log.Printf、log.Fatal 只是函数名不同，底层都调用同一套输出逻辑，log.Fatal 唯一特殊行为是调用 os.Exit(1)。
所谓“分级”，只能靠人工约定前缀，比如：
log.Printf("[INFO] user login: %s", username)
log.Printf("[ERROR] db query failed: %v", err)
- 前缀纯属字符串，无法过滤、无法设置不同输出目标（比如 ERROR 写文件，INFO 写 stdout）
- 如果真需要分级，应切换到
zap、zerolog或logrus—— 它们不是对log包的封装，而是完全独立实现 - 哪怕只是临时加个
[WARN]，也建议写个简单 wrapper 函数，避免重复拼接字符串
标准 log 包适合原型验证或极简 CLI 工具；一旦服务要上生产，分级、结构化、上下文注入这些需求，它就力不从心了。别硬撑，该换就换。
