Go slog.Handler.Enabled 怎样跳过低级别日志的昂贵计算

如果 Debug 日志关闭，昂贵的诊断数据仍可能在调用 slog.Debug 前就被计算出来。原因是 Go 会先求值函数参数，再进入日志方法；真正决定记录是否被处理的是 Handler 的 Enabled 判断。解决办法是：在构造字段、格式化字符串或采集诊断信息之前，先调用 logger.Enabled(ctx, slog.LevelDebug)。

官方地址：https://pkg.go.dev/log/slog

把 Enabled 当作“昂贵工作闸门”，而不是把它当作日志输出后的过滤器。低级别日志关闭时，闸门之前的计算不会发生；单个字段需要延迟时，再使用 LogValuer。

先分清参数求值和 Handler 过滤

slog.Logger 会把日志调用组织成记录，再交给关联的 Handler。Handler 可以根据级别决定是否处理记录，但这一步发生在调用参数已经准备好之后。因此下面的昂贵函数，即使 Debug 没有开启，也会先执行。

package main

import (
    "context"
    "log/slog"
)

func collectTrace() map[string]any {
    // 模拟采集调用栈、查询诊断指标等昂贵工作。
    return map[string]any{"span_count": 12}
}

func logDebug(logger *slog.Logger, ctx context.Context) {
    // 参数会先求值，Handler 之后才有机会过滤 Debug 记录。
    logger.DebugContext(ctx, "request trace", "trace", collectTrace())
}

这段代码的风险不在日志格式，而在 collectTrace() 的调用位置。低级别日志常常在生产环境关闭，却仍被高频请求触发；此时计算、分配和临时对象都可能成为不必要的成本。

在昂贵字段构造前调用 logger.Enabled

当一整段日志都需要采集诊断数据时，直接在入口处判断级别最清楚。logger.Enabled 会把调用转交给底层 Handler 的 Enabled 方法；如果底层配置的最低级别高于 Debug，就立即返回 false。

func logRequestDebug(logger *slog.Logger, ctx context.Context, requestID string) {
    // 先判断级别，关闭 Debug 时不采集和分配诊断字段。
    if !logger.Enabled(ctx, slog.LevelDebug) {
        return
    }

    trace := collectTrace()
    attrs := []slog.Attr{
        slog.String("request_id", requestID),
        slog.Any("trace", trace),
    }
    // LogAttrs 接收已经构造好的 Attr，适合这一类结构化字段。
    logger.LogAttrs(ctx, slog.LevelDebug, "request trace", attrs...)
}

判断要紧贴昂贵工作的前面。若在判断之前先调用 fmt.Sprintf、读取文件、遍历大对象或生成完整的 map，节省效果就会被抵消。对于正常的字符串和少量标量，不必为了每一行日志都增加判断；把判断留给确实有成本的部分。

封装格式化日志时也要提前判断

旧代码常见的辅助函数会先执行 fmt.Sprintf，再调用 logger.Debug。可以把级别判断放进辅助函数，让调用方不容易遗漏。

package main

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

func debugf(ctx context.Context, logger *slog.Logger, format string, args ...any) {
    // 先判断再格式化，避免 Debug 关闭时创建无用字符串。
    if !logger.Enabled(ctx, slog.LevelDebug) {
        return
    }
    message := fmt.Sprintf(format, args...)
    logger.DebugContext(ctx, message)
}

func useDebugf(ctx context.Context, logger *slog.Logger, userID string) {
    // 只有 Debug 被接受时，格式化工作才会执行。
    debugf(ctx, logger, "load profile for user=%s", userID)
}

如果辅助函数还要添加结构化属性，优先设计成接收 slog.Attr 或使用 LogAttrs，不要把所有字段拼进一条字符串。这样既保留可查询字段，也能把真正昂贵的准备工作放到 Enabled 之后。

单个值昂贵时用 LogValuer 延迟计算

有时整条日志不昂贵，只有一个值需要计算。这时可以让值实现 slog.LogValuer，把工作延迟到 Handler 真正需要解析该值时。它适合封装单个诊断对象，也能避免业务调用处到处写级别判断。

type lazyTrace struct {
    requestID string
}

func (v lazyTrace) LogValue() slog.Value {
    // 只有日志级别已启用且 Handler 需要解析该值时才采集诊断数据。
    return slog.AnyValue(collectTraceFor(v.requestID))
}

func collectTraceFor(requestID string) map[string]any {
    // 真实项目中这里可以读取请求级指标，但应保持无副作用。
    return map[string]any{"request_id": requestID, "span_count": 12}
}

func logLazy(logger *slog.Logger, ctx context.Context, requestID string) {
    // 传入惰性值，不在调用点直接执行 collectTraceFor。
    logger.DebugContext(ctx, "request trace", "trace", lazyTrace{requestID: requestID})
}

LogValuer 更适合“一个字段需要延迟”的场景；如果一整段日志包含多个昂贵步骤，仍然建议用 Enabled 做外层短路。无论选哪种方式，延迟计算函数都应避免修改共享状态，因为同一值可能由不同 Handler 或包装器处理。

用 HandlerOptions.Level 和 LevelVar 做回归检查

内置 TextHandler 与 JSONHandler 都支持 HandlerOptions.Level。固定的 slog.LevelInfo 会过滤 Debug；使用 *slog.LevelVar 则可以在多 goroutine 环境下安全地调整级别。

var programLevel slog.LevelVar

func newLogger() *slog.Logger {
    // LevelVar 默认是 Info，Debug 调用在默认配置下会被过滤。
    programLevel.Set(slog.LevelInfo)
    handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level: &programLevel})
    return slog.New(handler)
}

func enableDebug() {
    // 运维开关改变后，后续 Enabled 判断会看到新的级别。
    programLevel.Set(slog.LevelDebug)
}

示例中的 os.Stdout 需要导入 os；如果把这段代码放进完整程序，初始化和开关修改应由应用生命周期统一管理。回归时至少覆盖三种状态：Debug 关闭时昂贵函数不执行，Debug 打开时字段能进入记录，级别动态切换后新的调用能使用新配置。

选择哪种写法：一张表看清边界

常见问题

logger.Enabled 会不会直接输出日志？

不会。它只询问 Handler 是否启用某个级别，不会创建或写出一条记录。

只用 HandlerOptions.Level 就够了吗？

它能过滤记录，但不能阻止调用点在过滤前执行的函数参数。只要字段构造有明显成本，仍应提前使用 Enabled 或 LogValuer。

所有日志都要包一层 Enabled 吗？

不需要。普通字符串和少量标量的成本通常很低；优先保护采集快照、序列化、格式化和大对象遍历等真正昂贵的工作。

LogValuer 可以替代 Enabled 吗？

不能完全替代。它适合单个值的延迟解析；当多项工作都需要跳过时，外层 Enabled 更直观，也更容易在代码审查中确认短路范围。

最终原则很简单：Handler 负责决定“这条记录要不要处理”，调用方负责决定“在这之前要不要做昂贵工作”。把两者的边界放对，低级别日志关闭时才能真正省下计算和分配。