Go slog 的 LogValuer 什么时候值得用：避免热路径重复计算日志字段

服务已经接入 log/slog，但每条日志都先拼好请求对象、用户标签和调试快照，低级别日志关闭时仍然白算一遍。这个场景下，slog.LogValuer 值得用来推迟昂贵字段的展开；普通的字符串、整数和已经算好的状态则不必为了“高级写法”再包一层。

判断标准很简单：字段计算本身明显有成本，且当前 Handler 可能因为级别过滤而丢弃这条日志，就把计算放进 LogValue；便宜字段直接用 slog.String、slog.Int。

LogValuer 解决的是哪一段浪费

slog 在 Go 1.21 进入标准库，结构化日志的入口可以用 LogAttrs 明确构造属性。真正容易被忽略的是：日志记录可能还没到 Handler，调用方就已经把一大坨调试信息算完了。

下面这个 RequestSnapshot 把请求体摘要和标签拼接放进 LogValue。它不承诺每次都更快，而是把“什么时候计算”交给日志处理链。

type RequestSnapshot struct {
    UserID   int
    Path     string
    DebugRaw []byte
}

func (r RequestSnapshot) LogValue() slog.Value {
    return slog.GroupValue(
        slog.Int("user_id", r.UserID),
        slog.String("path", r.Path),
        slog.String("body_sha", sha256Hex(r.DebugRaw)),
    )
}

这里的真实节点是 slog.LogAttrs、Handler.Enabled 和 LogValuer.LogValue：调用方提交属性，Handler 先判断是否处理，值需要展开时才调用 LogValue。

一段最小可运行写法

把快照作为属性传入，而不是在调用 LogAttrs 之前手动执行 sha256Hex。如果当前 Handler 的级别不会输出这条记录，昂贵字段就没有必要展开。

logger.LogAttrs(ctx, slog.LevelDebug, "request detail",
    slog.Any("request", RequestSnapshot{
        UserID: 42,
        Path:   "/orders",
        DebugRaw: body,
    }),
)

为了验证行为，可以在测试用的 LogValuer 里增加计数器，再分别使用启用和关闭 Debug 的 Handler。注意不要把竞态计数器放进生产对象；测试里用 atomic.Int64 或单线程断言即可。

它和“先算好再打日志”有什么不同

先算好再传入的写法更容易读，也适合短字符串和已经存在的状态：

logger.LogAttrs(ctx, slog.LevelInfo, "order accepted",
    slog.String("order_id", orderID),
    slog.Int("items", len(items)),
)

如果 items 已经是内存切片，len(items) 几乎没有值得延迟的成本。相反，遍历大对象、做摘要、拼装一组日志字段时，LogValuer 才有明确收益。第二张图只保留 cheap field、expensive field、JSON 输出 三个正文节点，表示这条取舍。

采用前要避开的三个边界

不要在 LogValue 里做网络请求

LogValue 发生在 Handler 解析值的路径中。把数据库查询、HTTP 请求或等待锁放进去，会让“写日志”突然变成不可控的业务依赖。

不要把脱敏寄托在调用方自觉

密码、令牌和完整请求体不应因为实现了 LogValuer 就自动安全。返回的字段仍然要明确白名单，必要时直接返回 slog.String("redacted", "true") 这类可验证标记，而不是原始内容。

小心递归解析

Value.Resolve 会重复调用 LogValue，直到得到普通值或达到内部限制。不要让 LogValue 返回继续指向自己的值，也不要用互相引用的包装类型测试“无限展开”。

相关问题

LogValuer 会让所有日志都变快吗？

不会。它只在字段计算昂贵且日志可能被级别过滤时更有价值；便宜字段直接构造 Attr 通常更合适。

应该使用 Info 还是 LogAttrs？

属性较少且调用不频繁时两者都能工作；高频路径或希望显式构造属性时，优先使用 LogAttrs。

LogValue 可以读取 context.Context 吗？

不能直接从 LogValuer 方法参数取得 context。需要上下文信息时，在业务层先提取并作为字段传入。

最后的判断

先看字段成本，再看日志级别过滤，最后检查 LogValue 是否纯粹、有限、可脱敏。满足这三点时，LogValuer 是一个小而实用的延迟计算边界；否则，普通 slog.Attr 反而更稳。