Go slog.LevelVar 如何动态调日志级别：并发修改、Handler 读取与回滚

线上排查问题时，最麻烦的不是把日志调到 DEBUG，而是调完忘了收回来：请求量一上来，磁盘很快被细节日志占满。Go 1.21 引入的 log/slog 提供了 slog.LevelVar，可以让 Handler 在进程内安全地读取一个可变日志门槛。

需要动态切换日志级别时，把同一个 *slog.LevelVar 传给 slog.HandlerOptions.Level，通过 Set 更新；它默认是 INFO，更新成功后新产生的日志会按新门槛判断。

固定级别和动态级别差在哪里

slog.HandlerOptions.Level 接收的是 slog.Leveler。直接传 slog.LevelInfo 时，Handler 每次都按固定值判断；传入 *slog.LevelVar 时，Handler 会在判断一条记录是否应该输出时读取当前值。

var level slog.LevelVar // 零值就是 INFO
handler := slog.NewJSONHandler(os.Stderr, &slog.HandlerOptions{Level: &level})
logger := slog.New(handler)

logger.Debug("not visible at INFO")
level.Set(slog.LevelDebug)
logger.Debug("visible after switch")

这里的关键是指针：LevelVar 本身保存可变状态，传值会复制内部原子值，不能把复制品当成同一个运行时开关。通常把它作为进程级配置对象，和 logger 一起初始化。

把配置更新限制在一个可回滚入口

不要让业务代码到处调用 Set。更稳妥的做法是集中处理外部配置：先把字符串解析成合法的 slog.Level，校验通过后再替换当前级别，解析失败则保留旧值。

func setLogLevel(levelVar *slog.LevelVar, text string) error {
    var next slog.Level
    if err := next.UnmarshalText([]byte(text)); err != nil {
        return fmt.Errorf("invalid log level %q: %w", text, err)
    }
    levelVar.Set(next)
    return nil
}

// 配置中心返回 "DEBUG" 后切换；返回 "TRACE" 时旧级别不变。
if err := setLogLevel(&level, "DEBUG"); err != nil {
    log.Printf("keep current level: %v", err)
}

UnmarshalText 支持标准的 DEBUG、INFO、WARN、ERROR 以及带偏移的级别表达式。它不等于配置持久化：进程重启后仍要从环境变量、配置文件或配置中心重新初始化。

并发 Set 时 Handler 会读到什么

LevelVar.Set 和 LevelVar.Level 使用原子操作，所以多个 goroutine 同时更新和读取不会因为半写入而得到损坏的整数。它解决的是内存可见性，不是业务上的“最后一次配置一定赢”协议。

例如两个管理请求几乎同时设置 WARN 和 DEBUG，最终级别取决于两次 Set 的先后。如果需要按版本号拒绝旧配置，先在配置层比较版本，再调用 Set；不要把这个顺序约束寄托在 LevelVar 上。

测试切换、回滚和竞争检查

测试不必检查具体 JSON 字符串的全部字段，先验证门槛行为即可。INFO 默认应隐藏 DEBUG，切到 DEBUG 后应放行，解析非法值后应维持原级别。

func TestSetLogLevel(t *testing.T) {
    var level slog.LevelVar
    if got := level.Level(); got != slog.LevelInfo {
        t.Fatalf("zero LevelVar = %v, want INFO", got)
    }
    if err := setLogLevel(&level, "DEBUG"); err != nil {
        t.Fatal(err)
    }
    if got := level.Level(); got != slog.LevelDebug {
        t.Fatalf("level = %v, want DEBUG", got)
    }
    if err := setLogLevel(&level, "TRACE"); err == nil {
        t.Fatal("TRACE should be rejected")
    }
    if got := level.Level(); got != slog.LevelDebug {
        t.Fatalf("invalid update changed level to %v", got)
    }
}

并发场景用 go test -race ./... 跑一遍。若管理接口还维护了“配置版本、操作者、过期时间”等字段，应把这些字段的并发保护和 LevelVar 的原子读写分开测试。

上线前的几个边界

• DEBUG 可能带出请求参数、SQL 片段或内部地址，切换接口必须有鉴权和审计。
• 级别切换最好带自动回滚时间，排障结束后主动恢复 INFO。
• 多实例服务要明确切换范围：单实例热更新不能代表整个集群已经同步。
• Handler 创建后仍引用同一个 LevelVar；如果重建 Handler，别忘了继续传入当前配置对象。

常见问题：LevelVar 的使用疑问

LevelVar 的零值是什么级别？

零值对应 slog.LevelInfo。不需要额外初始化也能作为 Handler 的级别来源。

LevelVar 能跨进程同步日志级别吗？

不能。它只负责当前 Go 进程内的安全读写，多实例同步需要配置中心、管理接口或其他外部机制。

直接修改 LevelVar 会让已经写出的日志重放吗？

不会。它只影响后续 Handler 判断；已经被丢弃或已经写出的记录都不会因为 Set 而改变。

为什么非法级别不应该先 Set 再回滚？

因为校验失败时保留旧值更安全。先解析、后 Set 可以避免短暂进入一个不可用门槛，也让回滚语义变得明确。

把 LevelVar 当成日志门槛，而不是完整配置中心，通常就能把热切换做得足够简单：统一入口校验输入，成功后调用一次 Set，排障完成再恢复 INFO，测试里补上默认值、非法值和并发竞争三个边界。