Go slog.Handler.Enabled 为什么会提前过滤日志：级别判断与属性构造边界

线上把日志级别从 INFO 调到 WARN 后，磁盘压力下降了，但一段“准备调试字段”的代码仍然在每个请求里运行。问题通常不在 slog 没过滤，而在昂贵计算放在了调用点，早于级别判断。理解 Logger.Enabled、Handler.Enabled 和 slog.Record 的先后关系，才能把无效工作真正挡住。

Handler.Enabled 负责告诉 Logger 某个级别是否值得处理；级别未启用时，记录不会进入 Handler.Handle。但作为参数传入的函数或表达式，仍会先在调用点求值。

先看清一条日志经过了哪些对象

log/slog 把一个 Logger 绑定到一个 Handler。调用 Logger.LogAttrs 或 Logger.Info 时，日志级别先经过 Logger.Enabled。随后由 Handler.Enabled 给出是否处理的判断；只有通过后，才会形成 slog.Record 并进入 Handler.Handle。

这条链路解释了一个容易混淆的现象：关闭 DEBUG 后，处理器里的格式化和输出没有发生；但调用参数本身如果已经被计算，处理器也无法把它撤销。

package main

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

func main() {
    handler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo})
    logger := slog.New(handler)
    ctx := context.Background()

    if logger.Enabled(ctx, slog.LevelDebug) {
        logger.DebugContext(ctx, "cache probe", "value", expensiveAttrs())
    }
}

func expensiveAttrs() string {
    // 这里可以代表 JSON 编码、堆栈整理或数据库统计。
    return "computed"
}

上面的写法把 expensiveAttrs() 放在 logger.Enabled 之后，所以当处理器最低级别是 INFO 时，它不会被调用。反过来，如果直接写 logger.Debug("cache probe", "value", expensiveAttrs())，函数参数会在进入日志方法前求值。

分层检查：到底是日志被过滤，还是字段先算完了

第一层：确认 Handler.Enabled 的级别边界

先用同一个处理器检查两个级别。Logger.Enabled(ctx, slog.LevelDebug) 返回 false，而 Logger.Enabled(ctx, slog.LevelInfo) 返回 true，说明级别配置正在生效。这个判断不等于“所有参数都没有计算”，它只说明后续的日志记录不会被处理。

第二层：让昂贵计算留下可观察证据

实际排查时不要靠猜。用一个计数器包住 expensiveAttrs，先在 Logger.Enabled 为真的分支外调用一次，再放进分支内调用一次，比较计数变化。这样能区分“Handler 没收到记录”和“调用点已经做完无用工作”这两种情况。

var calls atomic.Int64

func expensiveAttrs() string {
    calls.Add(1)
    return "computed"
}

if logger.Enabled(ctx, slog.LevelDebug) {
    logger.LogAttrs(ctx, slog.LevelDebug, "cache probe",
        slog.String("value", expensiveAttrs()))
}
// DEBUG 未启用时，calls 应保持不变。

这里使用 LogAttrs 只是让属性写法更清晰；是否过滤仍由关联的 Handler.Enabled 决定。测试的成功状态应该是：输出中没有 DEBUG 记录，且 calls.Load() 没有增加。

修复动作：把成本高的字段放到启用判断之后

适合长期保留的写法，是先用 Logger.Enabled 做门槛，再准备字段。字段计算需要多个步骤时，可以把它们封装在分支内部；不要把一个返回字符串的函数当作“惰性属性”传给普通日志调用。

if logger.Enabled(ctx, slog.LevelDebug) {
    snapshot := buildDebugSnapshot(requestID)
    logger.LogAttrs(ctx, slog.LevelDebug, "request snapshot",
        slog.String("request_id", requestID),
        slog.String("snapshot", snapshot))
}

若只需要固定字面量，直接写入 LogAttrs 即可，不必为了所有字段都增加判断。判断的目标是昂贵、偶发或会触发外部访问的计算，例如整理大对象、读取额外文件或构造完整调用栈。

反向验证：测试过滤和成本控制两个结果

测试处理器时，除了断言 Handler.Handle 没有收到 DEBUG 记录，还应断言昂贵函数的计数没有增加。把最低级别改为 DEBUG 再运行一次，预期是 Handler.Handle 收到一条 slog.Record，计数器增加，输出包含 request snapshot。

如果日志仍然很多，检查 HandlerOptions.Level、是否替换了默认 Handler，以及调用点是否在启用判断之外。若只看到字段计算变慢，则先移动计算位置，不要急着改日志格式。

相关问题

Handler.Enabled 和 Logger.Enabled 是重复调用吗？

通常由 Logger.Enabled 询问关联的 Handler.Enabled。应用代码直接调用 Logger.Enabled 是为了在构造昂贵字段前做一次可见门控。

DEBUG 未输出时，LogAttrs 的参数还会不会求值？

写在 Logger.Enabled 分支里的表达式不会执行；直接作为 LogAttrs 参数的普通函数调用，仍会先求值。

什么时候不值得增加 Enabled 判断？

固定字符串、少量整数和已经存在的字段通常成本很低。只有在字段构造明显昂贵，或会触发额外 I/O、编码和堆栈整理时，门控才有稳定收益。

检查清单

• 确认 HandlerOptions.Level 与目标级别的关系。
• 确认 Logger.Enabled 返回值和 Handler.Enabled 的实际判断一致。
• 确认 expensiveAttrs 位于启用分支内部。
• 确认测试同时覆盖输出结果和调用次数。