Go slog.Logger.Enabled 怎样避免构造不会输出的日志参数

在 Go 的结构化日志中，slog.Logger.Enabled(ctx, level) 用来判断某个级别的日志是否会被当前 Handler 接收。要避免构造不会输出的昂贵参数，关键是把这个判断放在参数计算之前；如果只是把函数结果直接写进 Debug 参数，日志被过滤并不会阻止 Go 先执行这个函数。

官方文档：https://pkg.go.dev/log/slog#Logger.Enabled

简单规则：普通字符串和轻量参数直接记录；需要查询、序列化或大对象计算的参数，先用 Logger.Enabled 做分支，或者交给 LogValuer 延迟求值。

先用 HandlerOptions.Level 建立级别门槛

Logger.Enabled 的结果不是一个全局常量，它取决于 Logger 关联的 Handler、传入的上下文和日志级别。先把 Handler 的最低级别设为 Info，就能清楚观察到 Debug 不会进入输出路径。

package main

import (
    "context"
    "log/slog"
    "os"
)

func main() {
    // 只接收 Info 及以上级别，Debug 会被 Handler 过滤。
    opts := &slog.HandlerOptions{Level: slog.LevelInfo}
    logger := slog.New(slog.NewTextHandler(os.Stderr, opts))
    ctx := context.Background()

    // 用同一个上下文和级别询问当前 Logger 是否会输出。
    if logger.Enabled(ctx, slog.LevelDebug) {
        payload := buildPayload()
        logger.DebugContext(ctx, "debug detail", "payload", payload)
    }

    // Info 满足 Handler 的级别门槛，可以正常进入处理流程。
    logger.InfoContext(ctx, "service started")
}

func buildPayload() string {
    // 真实项目中这里可能包含序列化、查询或大对象整理。
    return "expensive-payload"
}

这个例子里，buildPayload 位于 Enabled 分支内部，所以 Debug 关闭时不会调用它。判断通过后再调用 DebugContext，既保留了日志级别语义，也把额外计算限制在真正需要的路径上。

为什么日志关闭了，函数还会执行

函数参数遵循 Go 的普通求值规则。下面的写法看起来像“Debug 关闭就不计算”，实际顺序是先执行 computeExpensiveValue，再把返回值交给日志方法：

// 直接参数会先求值，日志是否启用不会改变这个调用顺序。
logger.DebugContext(ctx, "debug detail", "payload", computeExpensiveValue())

因此，Enabled 解决的是“要不要进入这段昂贵逻辑”的问题，而不是让已经写在参数表达式里的计算自动变懒。查询数据库、拼接大 JSON、读取文件或计算复杂诊断信息，都应该放到分支内部，或者使用下一节的惰性值。

用 LogAttrs 和 LogValuer 延迟昂贵值

当一个值需要作为结构化属性传递，但它的计算成本较高时，可以让属性携带一个实现 slog.LogValuer 的类型。Handler 真正处理记录时才会解析这个值；没有启用该级别时，昂贵函数不会被调用。

type lazyPayload struct {
    id int
}

func (p lazyPayload) LogValue() slog.Value {
    // 只有日志记录被实际处理时，才计算昂贵内容。
    return slog.StringValue(computeExpensiveValue(p.id))
}

func writeDebug(logger *slog.Logger, ctx context.Context, id int) {
    // LogAttrs 只接收 Attr，结构比交替 key/value 参数更明确。
    logger.LogAttrs(ctx, slog.LevelDebug, "debug detail",
        slog.Int("id", id),
        slog.Any("payload", lazyPayload{id: id}),
    )
}

func computeExpensiveValue(id int) string {
    // 示例只返回文本；实际项目可在这里封装查询或序列化。
    return "payload-" + fmt.Sprint(id)
}

上面的完整示例还需要导入 fmt。LogAttrs 适合已经准备好的属性，LogValuer 则把“准备值”的动作推迟到了值真正被解析时。二者解决的是参数组织和求值时机，不是替代日志级别配置。

import "fmt" // 提供示例中的整数到字符串转换

Logger.Enabled 的几个边界

还要注意，Logger.Enabled 只是“当前 Logger 是否会发出该级别记录”的查询，不等于业务条件判断，也不保证后续代码永远不会改变 Handler 配置。把它靠近昂贵参数构造处，最容易保持代码意图清楚。

结语

处理昂贵日志参数时，先看求值时机：直接写进参数的函数会立即执行；放进 Enabled 分支则只有级别开启才执行；实现 LogValuer 可以把结构化值的计算进一步推迟。普通日志保持直写，只有真正有成本的参数才引入这层控制，代码会更容易读和维护。

相关问题

Logger.Enabled 和 Handler.Enabled 有什么区别？

Handler.Enabled 是处理器接口上的级别判断；Logger.Enabled 面向调用方，返回当前 Logger 是否会发出该级别的记录。

使用 LogValuer 后还需要手写 Enabled 分支吗？

如果只需要延迟单个属性的计算，LogValuer 通常足够；如果整段日志准备流程都很重，仍然可以先用 Enabled 跳过整段流程。

为什么推荐 LogAttrs？

它只接收 slog.Attr，能减少交替键值参数的歧义，并更适合与惰性结构化值一起使用。