Go slog.HandlerEnabled 怎么减少无效日志开销：日志级别判断与属性构造边界

把服务的日志从字符串拼接换成 log/slog 后，最容易误判的一点是：某条 Debug 日志没有出现在终端，就代表它没有成本。真正的边界取决于 Handler.Enabled 何时返回，以及昂贵字段是在调用参数里提前算完，还是交给 LogValuer 延后解析。

先记住一句话：Enabled 能挡住记录处理，但挡不住调用表达式本身；把昂贵计算放进 LogValuer，或先用 Logger.Enabled 判断，才能把无效日志的主要成本一起挡住。

先搭一个能看见调用顺序的 slog 实验

实验只需要一个标准库程序。把下面代码保存为 main.go，运行时使用默认的 Info 门槛。slowFields 用计数器模拟昂贵属性构造，重点不是测纳秒，而是观察它到底有没有被调用。

package main

import (
    "context"
    "fmt"
    "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("discarded", slowFields())
    logger.Debug("deferred", deferredFields{})
    logger.InfoContext(context.Background(), "kept", slowFields())
    fmt.Println("field calls:", fieldCalls.Load())
}

运行 go run . 后，终端只会看到 Info 记录和计数结果。这个结果先别下结论：第一条 Debug 的 slowFields() 已经在调用 Debug 前求值，第二条则把工作放到了 LogValuer，只有记录真正进入处理阶段时才解析。

为什么 Handler.Enabled 能省成本，却不能拦截参数表达式

官方 Handler 约定把 Enabled 放在记录处理的早期。调用链可以简化为 Logger.LogAttrs 先询问 Handler.Enabled，被接受后再处理 LogValuer，最后交给 Handle。因此低级别记录不会进入后两步。

但 Go 的参数求值发生在函数调用之前。logger.Debug("discarded", slowFields()) 中的 slowFields() 不属于 Handler 能控制的阶段；它已经返回了一个 slog.Attr。如果字段构造要访问大对象、读取上下文或做序列化，这笔开销仍然发生。

把昂贵字段放到 LogValuer

deferredFields 的 LogValue 是延迟边界。记录被 Info Handler 拒收时，解析不会发生；记录进入 Handle 时才会调用 slowFields。这种方式适合字段值有明确的延迟计算成本，但不要把有副作用的业务动作塞进 LogValue，日志开关不应改变业务状态。

用 Logger.Enabled 包住仍然昂贵的计算

如果字段不是一个轻量的 LogValuer，而是必须先得到结果再拼成多个 Attr，可以先检查 Logger 的门槛。

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)),
    )
}

这里的条件判断只负责保护 loadRequestSnapshot。真正写日志仍用 LogAttrs，因为它直接接收 Attr，少了一层键值参数的解释。若 Debug 被关闭，快路径不会读取快照；若 Debug 打开，快照和记录会一起进入当前 Handler。

不要把所有日志都包上这层判断。普通字符串和几个整数的构造成本很低，过度包裹会让代码失去可读性。把判断留给数据库查询、深拷贝、JSON 编码或大对象遍历等可见成本。

LevelVar 如何做运行中的日志门槛切换

HandlerOptions.Level 接受 slog.Leveler。使用 LevelVar 后，可以在不替换 Handler 的情况下调整最低级别：

var level slog.LevelVar

func newLogger() (*slog.Logger, *slog.LevelVar) {
    level.Set(slog.LevelInfo)
    handler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: &level})
    return slog.New(handler), &level
}

logger, level := newLogger()
logger.Debug("hidden")
level.Set(slog.LevelDebug)
logger.Debug("visible")
logger.Info("still visible")

第一次 Debug 在 Info 门槛下被丢弃；level.Set 后，第二次 Debug 能通过同一个 Handler。图里的 slog.Info 仍保持可见，表示调整 Debug 门槛不会改变 Info 记录的正常通路。线上切换时要注意并发读写规则：让配置入口只修改 LevelVar，不要在每次请求里重新创建 Handler 和 Logger。

检查结果：从计数器判断优化是否真的生效

把 fieldCalls.Load() 的结果作为实验验收点。只看终端有没有 Debug 文本不够，因为文本不出现并不等于参数没有准备。可以再加一个测试 Handler，分别记录 Enabled、Handle 和 LogValue 的调用次数，确认关闭 Debug 时只有前置判断发生。

若日志来自多个 Handler，例如同时写终端和文件，任何一个 Handler 接受该级别，都可能让记录继续处理。自定义 Handler 还必须安全处理并发调用，不能把一次实验里的计数器写法直接照搬到业务状态。

常见问题

直接调用 slog.Debug 会自动跳过所有参数计算吗？

不会。函数参数先求值，昂贵函数仍会运行。可以使用 Logger.Enabled 包住计算，或把纯读取型字段放进 LogValuer。

LevelVar.Set 后需要重新创建 Logger 吗？

不需要。只要 HandlerOptions.Level 使用的是同一个 LevelVar，修改它就会影响后续记录。

LogValuer 里可以查询数据库吗？

不建议。日志过滤会改变它是否被调用，把数据库查询放进去会让日志配置间接改变业务负载。应在明确的启用判断后准备可控的快照。

总结

Handler.Enabled 是结构化日志的早期过滤点，LogValuer 是字段解析的延迟点，Logger.Enabled 则适合保护必须提前计算的昂贵数据。用计数器和调用顺序做一次小实验，很快就能分清“日志没打印”和“日志没有成本”不是一回事。