Go slog.LogValuer 为什么会拖慢日志：昂贵字段延迟计算与等级过滤边界

服务切到 log/slog 后，日志量降下来了，CPU 却没有按预期下降，最常见的原因不是 Handler 失效，而是昂贵字段在调用日志方法前就已经算完。要分清这两笔成本，关键看 Handler.Enabled、LogValuer 和 Go 参数求值分别处在什么位置。

Handler.Enabled 可以挡住被丢弃记录的后续处理，但挡不住调用表达式本身；把可延迟的工作放进 LogValuer，把必须提前得到的数据放进 Logger.Enabled 判断，才能真正缩短 Debug 关闭时的快路径。

先用计数器看清两条日志路径

下面的实验不追求纳秒级基准，只记录昂贵字段构造了几次。保存为 main.go 后运行 go run .，默认 Handler 最低级别为 Info。

package main

import (
    "log/slog"
    "os"
    "sync/atomic"
)

var fieldCalls atomic.Int64

func slowFields() slog.Attr {
    n := fieldCalls.Add(1)
    return slog.Int64("field_calls", n)
}

type deferredFields struct{}

func (deferredFields) LogValue() slog.Value {
    return slowFields().Value
}

func main() {
    logger := slog.New(slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo}))
    logger.Debug("eager", slowFields())
    logger.Debug("deferred", deferredFields{})
    logger.Info("kept", slowFields())
    println("field calls:", fieldCalls.Load())
}

运行后只会看到 Info 记录，但计数器会把第一条 Debug 的字段构造算进去，第二条 Debug 的 LogValue 不会执行，Info 记录则会执行一次。这个结果就是基线：无效日志的输出成本为零，不代表参数准备成本也为零。

LogValuer 把昂贵计算推迟到 Handle

slog.Handler 的早期判断路径可以概括为：日志调用先让 Handler.Enabled 判断等级，拒绝时直接结束；接受后才进入属性解析和 Handle。实现 LogValuer 的 deferredFields 因此能避开关闭级别下的计算。

注意，logger.Debug("eager", slowFields()) 里的 slowFields() 是普通 Go 函数调用。函数参数必须在进入 Debug 之前求值，Handler 没有机会拦截它。换成 deferredFields{} 后，传入的是一个轻量值，真正的 LogValuer 才在记录需要被处理时运行。

LogValue 里不要放业务副作用

延迟不等于异步，也不保证一定执行。日志等级、Handler 类型和记录是否被丢弃都会影响它是否被调用，所以 LogValue 适合格式化、快照整理和只读计算，不适合扣库存、写数据库或改变请求状态。

必须先拿到结果时，用 Logger.Enabled 保护查询

有些数据无法包装成一个轻量的 LogValuer，例如要读取请求体摘要、遍历大集合，或先做一次 JSON 编码。这类工作要在构造 Attr 前检查 Logger.Enabled：

if logger.Enabled(ctx, slog.LevelDebug) {
    snapshot := loadRequestSnapshot(ctx)
    logger.LogAttrs(ctx, slog.LevelDebug, "request snapshot",
        slog.String("request_id", snapshot.ID),
        slog.Int("items", len(snapshot.Items)),
    )
}

这里的调用链是 Logger.Enabled 先读取当前 Handler 的等级判断；通过后才调用 loadRequestSnapshot，再由 Logger.LogAttrs 把已经准备好的 Attr 交给 Handler.Handle。Debug 关闭时，快路径不会读取快照。

用一个小基准确认优化是否值得

把 slowFields 替换成真实工作后再测，例如深拷贝请求对象或遍历 snapshot.Items。分别测试 Debug 关闭和打开两种状态，至少记录调用次数、每次请求耗时和 CPU 采样，避免只观察终端有没有日志。

对轻量字符串和整数，不必机械地包一层 Logger.Enabled；判断本身也有可读性成本。对数据库查询、文件读取、序列化和大对象遍历，则应把判断放在最靠近昂贵动作的位置。

常见误区与边界

只看到没有 Debug 文本就以为没有成本

先看昂贵函数的计数器或基准结果。输出被丢弃只说明记录没有完成 Handler 处理，不能说明参数表达式没有执行。

把所有字段都改成 LogValuer

小型纯值不值得增加包装层，要结合调用频率和代码可读性判断。更重要的是不要在 LogValue 中依赖一次性状态或副作用，否则调高日志级别可能意外改变业务行为。

用 Logger.Enabled 后又重新创建 Handler

Logger.Enabled 判断的就是当前 Logger 关联 Handler 的门槛。运行中调整级别时，应更新共享的 slog.LevelVar，不要在每个请求里重建 Logger，否则会把日志优化变成额外的对象和配置开销。

延伸问答

Handler.Enabled 会不会调用 LogValuer？

正常的优化路径不会。它先判断等级，记录被拒绝时后续的属性解析不会发生；真正的解析发生在 Handler 处理记录时。

为什么还需要 Logger.Enabled？

因为 LogValuer 只能延迟它包住的值，而查询、快照或编码往往必须先得到结果。用 Logger.Enabled 可以连同这些前置动作一起跳过。

总结

排查 slog 性能时，把“记录是否输出”和“参数是否已经计算”分开看。轻量值直接传入即可；可延迟的昂贵值交给 LogValuer；必须提前生成的数据则由 Logger.Enabled 保护。最后用计数器或基准验证快路径，结论才不会被终端表象带偏。