Go log/slog 怎样按级别丢弃调试日志

如果生产日志不想被调试信息淹没，关键不是在业务代码里到处加 if，而是给 slog.Handler 设置最低级别。把 HandlerOptions.Level 设为 slog.LevelInfo 后，Debug 记录会在交给输出处理器前被丢弃，Info、Warn 和 Error 仍然保留。

官方资料：https://pkg.go.dev/log/slog

如果需要临时打开调试日志，可以把级别交给 slog.LevelVar。它实现了 slog.Leveler，调用 Set 就能动态修改 Handler 的最低级别，而且适合被多个 goroutine 读取和调整。

先看懂 slog 的级别方向

slog 的级别数值越大，表示事件越严重：DEBUG=-4、INFO=0、WARN=4、ERROR=8。因此“只保留 INFO 以上”实际是在 Handler 中接受级别大于等于 INFO 的记录；DEBUG 的数值更小，会被过滤。

这里的“丢弃”发生在 Handler 的级别判断处，不等于业务调用没有执行。业务代码仍然会调用 logger.Debug，只是低于门槛的记录不会被 Handler 写到文本或 JSON 输出。

用 HandlerOptions.Level 设置固定门槛

最简单的做法是创建 Handler 时直接给 HandlerOptions.Level 一个固定值。下面的例子把标准错误输出作为文本日志目标，只接受 INFO 及以上记录。

package main

import (
    "log/slog"
    "os"
)

func main() {
    // 把最低级别固定为 INFO，DEBUG 记录不会交给 TextHandler。
    options := &slog.HandlerOptions{Level: slog.LevelInfo}
    handler := slog.NewTextHandler(os.Stderr, options)
    logger := slog.New(handler)

    // 这条调用仍然成立，但会被 Handler 的级别门槛过滤。
    logger.Debug("调试细节", "request_id", "req-1001")
    // INFO、WARN、ERROR 都不低于门槛，会继续写入输出。
    logger.Info("请求完成", "status", 200)
    logger.Warn("响应较慢", "duration_ms", 850)
    logger.Error("请求失败", "err", "upstream timeout")
}

这个配置适合生产环境的默认日志策略：级别规则集中在 Handler 上，业务调用不需要重复判断。若改用 slog.NewJSONHandler，过滤逻辑仍然由同一套 Handler 选项控制，只是最终格式变为逐行 JSON。

用 LevelVar 动态调整门槛

固定级别适合稳定配置，但排查线上偶发问题时，通常希望先保持 INFO，再在需要时打开 DEBUG。此时可以把 LevelVar 的地址作为 HandlerOptions.Level。

package main

import (
    "log/slog"
    "os"
)

func main() {
    var minimum slog.LevelVar
    // LevelVar 的零值是 INFO，所以默认不会输出 DEBUG。
    minimum.Set(slog.LevelInfo)

    options := &slog.HandlerOptions{Level: &minimum}
    logger := slog.New(slog.NewTextHandler(os.Stderr, options))

    logger.Debug("默认不可见", "phase", "startup")

    // 需要排障时切换为 DEBUG 以上，后续 Debug 记录即可写出。
    minimum.Set(slog.LevelDebug)
    logger.Debug("临时打开调试", "phase", "diagnose")

    // 排障结束后恢复 INFO，避免持续增加日志噪声。
    minimum.Set(slog.LevelInfo)
}

LevelVar.Set 修改的是级别变量，Logger 和 Handler 不需要重新创建。它的价值在于把“日志详细程度”变成一个可以由配置刷新、管理接口或诊断开关驱动的状态；具体的开关来源仍应由应用自行控制。

用 Enabled 提前判断昂贵的调试参数

级别过滤不仅影响最终输出，也可以避免准备昂贵的调试数据。若调试参数需要序列化、遍历大对象或计算耗时，可以先调用 Enabled。这一步与最终 Handler 的级别门槛保持一致。

// 只有 DEBUG 被当前 Handler 接受时，才计算昂贵的调试字段。
if logger.Enabled(ctx, slog.LevelDebug) {
    // 这里放入代价较高的诊断信息构造逻辑。
    detail := buildDebugDetail()
    logger.DebugContext(ctx, "调试信息", "detail", detail)
}

不要把所有日志都包在这种判断里；普通字符串和少量字段直接调用更易读。它主要服务于确实有计算成本的诊断数据。

默认 Logger 与多 Handler 的边界

如果代码使用包级的 slog.Debug、slog.Info 等函数，需要先通过 slog.SetDefault 设置默认 Logger，否则你配置好的 logger 不会自动替换包级默认值。

package main

import (
    "log/slog"
    "os"
)

func installDefaultLogger() {
    // 设置包级函数使用的默认 Logger，避免配置只挂在局部变量上。
    options := &slog.HandlerOptions{Level: slog.LevelInfo}
    slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stdout, options)))
}

当应用使用 slog.NewMultiHandler 时，每个子 Handler 都可以有自己的 Enabled 规则。一个 Handler 过滤掉 DEBUG，不代表另一个配置为 DEBUG 的 Handler 也会过滤；排查“为什么某个输出里还有调试日志”时，要逐个看 Handler 的级别设置。

常见问题

把最低级别设置成 WARN 会发生什么？

INFO 和 DEBUG 会被过滤，WARN 与 ERROR 会保留。级别越高，输出越少；不要把它误解成“只输出数值等于 WARN 的记录”。

LevelVar 的零值是什么？

零值对应 INFO。如果配置来自文本或环境变量，应用仍应在启动阶段明确解析并设置最终级别，避免把错误的输入默认为过于详细的日志。

过滤后还能恢复 DEBUG 吗？

可以。使用 LevelVar 时调用 Set(slog.LevelDebug)，后续记录会按新门槛判断；恢复生产状态时再设置回 slog.LevelInfo。

为什么 Debug 调用了却没有输出？

先看 Logger 绑定的 Handler，以及 HandlerOptions.Level 或 LevelVar 当前值；如果使用的是包级函数，再确认是否调用了 slog.SetDefault。调用成功不表示记录一定会被当前输出处理器接受。

小结

Go log/slog 丢弃调试日志的核心配置是 Handler 的最低级别：固定策略使用 HandlerOptions.Level: slog.LevelInfo，需要运行时切换则使用 slog.LevelVar。把过滤放在 Handler 层，可以让业务代码保持统一的日志调用；对昂贵的诊断参数，再用 Logger.Enabled 提前跳过计算。