不能直接用fmt.Sprintf拼接结构化日志，因其不校验字段名、不处理零值、不支持嵌套序列化，易导致字段错位、漏值、解析失败；且无性能优化，高频场景下内存分配压力大。
为什么不能直接用 fmt.Sprintf 拼接结构化日志
因为日志字段顺序、类型、空值处理全靠人肉拼，fmt.Sprintf 既不检查字段名重复，也不跳过零值字段，更无法按需序列化嵌套结构。一旦日志字段超过 4 个，输出就容易错位或漏字段，调试时根本分不清哪个值对应哪个 key。
常见错误现象：level=info msg="user login" user_id=123 ip= error= —— 最后一个 error= 后面没值，但调用方传了 nil，却没被跳过；或者 user_id 和 ip 位置互换，日志解析器直接丢弃整条。
- 结构化日志必须保证字段名与值一一映射，且顺序稳定（如始终按字典序或声明顺序）
- 零值（
0、""、nil）是否输出应由字段策略控制，不是统一忽略 - 高性能关键在于避免反射遍历、减少内存分配，尤其在高频请求中不能每条日志都
make([]interface{}, ...)
log/slog 的 Handler 接口是定制入口，不是装饰器
很多人把 slog.Handler 当成“加个前缀/改个时间格式”的中间件，结果写了一堆 h.Handle(r, attrs) 嵌套调用，性能掉一半。实际上 Handler 是最终落盘前的唯一可控环节，所有字段、级别、时间都已归一化为 slog.Record 和 []slog.Attr，这里才是做字段过滤、格式重排、JSON 序列化的正地方。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 不要在
Log方法里再调用其他 logger，避免递归或重复编码 - 用
record.Time和record.Level替代自己解析msg字符串里的时间/级别 - 若需支持
Attr.Group，必须递归展开Group.Value()，否则嵌套结构会变成group={}这种无意义占位 - 避免在
Handle中做任何阻塞操作（如网络请求、磁盘 sync），它在日志调用栈同步执行
自定义 Format 函数必须区分字段来源：key-value 对 vs. slog.Any 值
slog.String("user_id", "123") 和 slog.Any("req", &http.Request{}) 经过 Handler 后都变成 slog.Attr，但前者是明确键值对，后者可能触发任意深度反射。如果统一用 fmt.Sprint(v) 格式化，&http.Request{} 会输出几千字符的 debug 字符串，撑爆日志行或触发截断。
正确做法是分级处理：
- 基础类型（
string、int、bool）直接转字符串，不加引号（除非含空格或特殊字符） - 指针/结构体/切片等复杂类型，先判断是否实现了
fmt.Stringer，有则调用；否则只输出类型名 + 地址（如&User{0xc000123abc}），禁止深反射 - 明确标记为敏感字段（如
"password"、"token"）的值，一律替换为"<redacted>"</redacted>，不走任何格式化逻辑 - 时间类型优先用
time.Time.Format("2006-01-02T15:04:05.000Z07:00")，而非fmt.Sprint默认格式
性能瓶颈常藏在 JSON 序列化和内存复用上
用 json.Marshal 处理每条日志，即使字段少，也会触发至少 2 次内存分配（map 转 []byte + buffer 扩容）。高并发下 GC 压力陡增，pprof 显示 runtime.mallocgc 占比超 40%。
可落地的优化点：
- 预分配
bytes.Buffer，用buf.Reset()复用，避免每次 new - 字段数量固定且较少时（如 ≤8），手写 JSON 序列化逻辑，用
buf.WriteString拼接，比json.Encoder快 3–5 倍 - 对
Record.Time使用time.AppendFormat直接写入 buffer，绕过time.Format的字符串分配 - 避免在
Handler中构造新map[string]interface{}，它比扁平的[]slog.Attr多一次遍历和类型断言
真正难的是平衡可读性与性能：字段名排序提升可读性，但排序本身有开销；红action字段脱敏必须实时，但判断逻辑不能拖慢主路径。这些细节不压测根本看不出问题。
