slog 比 fmt.Printf 更适合生产环境，因其原生支持结构化字段、层级、采样和 Handler 分发，可被 Loki 等系统自动解析；fmt.Printf 仅输出不可解析的字符串，需正则提取且易失效。
log/slog 为什么比 fmt.Printf 更适合生产环境
因为 slog 天然支持结构化字段、层级、采样和 Handler 分发，而 fmt.Printf 输出只是字符串拼接，无法被日志系统（如 Loki、Datadog）自动解析字段。你写 slog.Info("user login", "user_id", 123, "ip", "192.168.1.5")，它就真能当 JSON 解析出 user_id 和 ip 字段；用 fmt.Printf 拼出来的字符串，得靠正则硬抠，一改格式就崩。
常见错误现象：slog.Info("user login user_id=123 ip=192.168.1.5") —— 这本质还是字符串，没用上结构化能力。
- 必须用键值对形式传参，且键必须是
string，值可以是任意类型（slog会自动序列化） - 避免在键里塞空格或特殊符号，比如
"user id"不如用"user_id"，部分后端解析器不认空格键 - 不要手动拼 JSON 字符串传给
slog，比如slog.Info("msg", "attrs", `{"a":1}`)—— 这会让嵌套结构丢失语义，变成一个字符串字段
如何让 slog 输出 JSON 而不是默认文本格式
默认 slog 用的是 slog.TextHandler，输出可读但不可解析的文本。要对接 ELK 或云日志服务，得换 slog.JSONHandler。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化 logger 时显式指定 handler：
logger := slog.New(slog.NewJSONHandler(os.Stdout, nil)) - 如果要用自定义时间格式，传
&slog.HandlerOptions{AddSource: true}第二个参数，但注意：加AddSource会轻微拖慢性能（需 runtime.Caller），开发调试开，线上慎开 - 注意 Go 1.21+ 的
slog.JSONHandler默认把时间转成 RFC3339 字符串，不需要额外配置；但如果你用第三方 handler（比如github.com/samber/slog-multi），行为可能不同，得看文档
用 WithGroup 组织日志上下文时容易漏掉什么
WithGroup 是给一批日志加统一前缀字段的好方法，比如所有数据库操作都带 db 分组，但它不会自动继承到子 goroutine —— 这是最常踩的坑。
常见错误现象：主线程调了 logger = logger.WithGroup("db")，然后起 goroutine 执行查询，结果日志里没 db 字段。
- Go 的
slog.Logger是值类型，复制后修改不影响原 logger；但 goroutine 里用的如果是旧 logger 变量，就丢了 group - 正确做法：把带 group 的 logger 显式传进 goroutine，或用
context.Context+ 自定义 value 传递（需配合 middleware 封装） - 别滥用嵌套 group，比如
logger.WithGroup("http").WithGroup("auth").WithGroup("token")—— 过深的 group 层级会让 JSON 字段名变成http.auth.token.xxx，部分日志平台字段名长度有限制（如 Loki 约 200 字符）
自定义 Handler 时怎么避免 panic 导致日志静默丢失
写自己的 slog.Handler（比如发到 HTTP endpoint）时，如果 handler 内部 panic，整个日志调用就静默失败，连 error 都不打 —— 因为 slog 默认不 recover。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
Handle方法最外层加defer func() { if r := recover(); r != nil { /* 记录到 stderr 或 fallback 日志 */ } }() - 网络类 handler 必须设超时，比如用
http.Client时配Timeout: 5 * time.Second，否则一次卡死会让后续所有日志阻塞 - 不要在
Handle里做复杂计算或锁操作，slog调用是同步的，卡住会影响业务逻辑执行速度
结构化日志真正难的不是怎么打，是怎么确保每条关键路径上的日志既不丢、不错、又不拖慢服务 —— 尤其在高并发或资源受限场景下，handler 的健壮性和资源控制比格式本身重要得多。
