Go slog 如何按级别过滤日志：HandlerOptions、日志级别与测试验证

线上服务把日志切到结构化格式后，最常见的下一步不是换日志库，而是先把“哪些级别应该落盘”定下来。Go 的 log/slog 可以在创建 Handler 时设置最低级别：例如生产环境只输出 INFO 及以上，排查问题时再用 LevelVar 动态放开 DEBUG。

HandlerOptions{Level: slog.LevelInfo} 会过滤 DEBUG；如果运行中需要调整级别，就把它换成可并发读写的 slog.LevelVar，并用测试缓冲区确认实际输出。

先把“最低级别”与日志调用分开看

slog.Level 是表示严重程度的整数，数值越高越严重。内置的 INFO、WARN、ERROR 和 DEBUG 只是常用档位。Handler 的最低级别不是“只允许一种级别”，而是允许该级别及更严重的记录通过。

package main

import (
    "os"
    "log/slog"
)

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

    logger.Debug("cache probe", "key", "user:42")
    logger.Info("request accepted", "status", 200)
    logger.Error("request failed", "status", 500)
}

运行后可以看到 INFO 和 ERROR，DEBUG 不会出现在 JSON 输出中。这里不要把 Level 理解成“日志调用开关”；它决定的是 Handler 是否启用某个级别。

固定级别的完整工作流：创建、记录、核对

第一步先选择输出格式。NewTextHandler 适合人直接查看，NewJSONHandler 适合采集系统逐行解析。第二步把最低级别放进 HandlerOptions，第三步在相同输出目标上核对结果。

var level = slog.LevelInfo

handler := slog.NewTextHandler(os.Stderr, &slog.HandlerOptions{
    Level:     level,
    AddSource: true,
})
logger := slog.New(handler)
logger.Info("worker started", "queue", "emails")

AddSource 只负责附加调用位置，不改变级别过滤。生产配置通常不需要为了“看见更多日志”而打开源码位置；先确认采集端真正缺的是级别还是字段。

需要临时排障时，用 LevelVar 调整而不是重建 Handler

固定的 slog.Level 会在 Handler 生命周期内保持不变。若希望管理员开关或诊断接口改变级别，可使用 LevelVar：

var programLevel slog.LevelVar // 默认是 INFO

func newLogger() *slog.Logger {
    h := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
        Level: &programLevel,
    })
    return slog.New(h)
}

func enableDebug() {
    programLevel.Set(slog.LevelDebug)
}

LevelVar 适合多个 goroutine 读取、单点修改的配置。它不是让所有请求都永久输出 DEBUG 的理由：打开后应有明确的关闭路径，并注意敏感字段可能随调试日志暴露。

用缓冲区测试过滤结果，而不是凭肉眼猜

测试时可以把 JSON Handler 的输出写入 bytes.Buffer，分别记录 DEBUG 和 INFO，再检查文本中是否出现预期消息。这个测试验证的是完整链路：调用级别、Handler 的 Enabled 判断以及最终编码。

func TestLogLevel(t *testing.T) {
    var buf bytes.Buffer
    var level slog.LevelVar
    level.Set(slog.LevelInfo)

    logger := slog.New(slog.NewJSONHandler(&buf, &slog.HandlerOptions{
        Level: &level,
    }))
    logger.Debug("hidden")
    logger.Info("visible")

    got := buf.String()
    if strings.Contains(got, "hidden") {
        t.Fatal("debug record should be filtered")
    }
    if !strings.Contains(got, "visible") {
        t.Fatal("info record should be written")
    }

    level.Set(slog.LevelDebug)
    logger.Debug("now-visible")
    if !strings.Contains(buf.String(), "now-visible") {
        t.Fatal("debug record should be enabled after level change")
    }
}

测试里最好检查稳定的消息字段，不要把时间戳、源码行号或 JSON 字段顺序当成断言重点。若只断言“缓冲区非空”，就无法证明 DEBUG 确实被拦截。

三个容易混淆的边界

最低级别不是采集端过滤

Handler 在记录进入编码流程前就会判断是否启用。采集端再过滤属于另一层策略，不能替代应用侧的级别设计。

LevelVar 不是每条日志都要重新读取配置文件

把配置刷新和日志调用绑在一起，会让热路径变复杂。集中维护一个 LevelVar，在配置变更时调用 Set，更容易测试和回滚。

打开 DEBUG 不等于可以记录所有参数

账号标识、令牌、请求体和内部地址仍要按敏感信息处理。级别开关解决可见性，不解决脱敏与访问权限。

上线前的速查与回滚动作

固定级别场景核对 HandlerOptions.Level 是否符合环境；动态场景核对 LevelVar 是否有默认值、修改入口和关闭动作；测试场景核对 DEBUG 未出现、INFO 出现、切换后 DEBUG 出现。若日志量或敏感字段异常，先把级别恢复为 INFO，再定位是谁修改了开关。

这套做法的关键不在于把日志开得更细，而在于让“过滤发生在哪里、何时改变、怎样证明”都能被代码和测试说清楚。

常见问题

HandlerOptions 的 Level 不设置时是什么级别？

内置 Handler 默认使用 INFO 作为最低级别，因此 DEBUG 默认不会输出。

LevelVar 能不能被多个 goroutine 使用？

可以。LevelVar 的设计支持并发读写，但业务代码仍应限制修改入口，避免不同配置源互相覆盖。

为什么测试要用 bytes.Buffer？

因为它能把 Handler 的真实输出保留下来，既能验证过滤，也能验证消息是否完成编码，比只检查函数返回更接近线上路径。