Go slog.LevelVar 怎么动态改日志级别：并发更新、Handler读取与回滚

线上排查接口延迟时，临时把日志级别调到 DEBUG 很常见。麻烦在于：如果 Handler 初始化时拿到的是一个固定的 slog.Level，管理接口即使返回“修改成功”，后续日志也不会增加。Go 的 slog.LevelVar 正好解决这个运行时开关问题，但前提是 Handler 读取的必须是同一个 LevelVar。

先看一个“改成功但没生效”的现场

假设服务启动时这样创建 Handler：

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

管理接口里再维护一个全局变量，接收到 debug 后把它改成 slog.LevelDebug。这个变量和 Handler 没有关系，Handler 仍然只认初始化时的 LevelInfo。所以“接口返回 200”只能证明配置被接收，不能证明日志过滤器已经换了。

这一点可以从输出直接确认：logger.Debug("cache probe") 始终不出现，而 logger.Info("config updated") 正常出现。先别急着给日志调用加更多参数，问题在级别值的所有权。

让 Handler 读取同一个 LevelVar

最小可用写法是把级别开关单独拿出来，并把它交给 HandlerOptions.Level：

var runtimeLevel slog.LevelVar

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

HandlerOptions.Level 接收的是 slog.Leveler。*slog.LevelVar 实现了这个接口，因此 Handler 每次判断一条记录时都能读到当前值，而不是复制一份启动时的快照。

用一个管理函数验证动态生效

func setLevel(name string) error {
    var level slog.Level
    if err := level.UnmarshalText([]byte(name)); err != nil {
        return err
    }
    runtimeLevel.Set(level)
    return nil
}

先调用 setLevel("DEBUG")，再输出一条 Debug 记录；能在终端看到 cache probe，说明 Handler 读到了同一个 LevelVar。随后调用 setLevel("INFO")，Debug 记录重新被过滤，Info 记录仍保留。这就是比“接口返回成功”更可靠的可见状态。

并发更新时，为什么不需要自己加读写锁

日志输出通常由多个请求协程同时触发，管理接口也可能在另一个协程更新级别。LevelVar 的设计就是把当前级别作为可并发访问的状态：日志 Handler 调用 Level()，配置入口调用 Set()，调用方不需要围绕这两个操作再包一层普通变量。

不过，这不等于整段配置流程天然原子。解析文本、校验业务范围、写入 LevelVar 是三个动作。正确顺序应该是“先在局部变量中解析，成功后一次 Set”：

func applyLevel(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)
    }
    runtimeLevel.Set(next)
    return nil
}

这样，两个请求同时提交时，最终结果只会是某一个已经解析成功的级别；一次非法输入不会把当前级别写成半成品。

非法配置如何保留旧值并完成回滚

生产环境更需要关注回滚。下面的规则足够实用：读取当前值只用于返回状态，真正更新只接受 UnmarshalText 已成功的局部值。

func changeLevel(w http.ResponseWriter, r *http.Request) {
    requested := r.URL.Query().Get("level")
    if err := applyLevel(requested); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    slog.Info("log level changed", "level", runtimeLevel.Level())
    w.WriteHeader(http.StatusNoContent)
}

例如当前级别是 DEBUG，请求 ?level=verbose 后应返回 400；下一条 Debug 日志仍然可见，说明旧值没有被污染。若请求 ?level=INFO 返回 204，随后 Debug 消失、Info 仍出现，回滚和恢复都完成了。

排查时最容易踩的三个边界

• 把 LevelVar 的值传给 Handler：Level: runtimeLevel.Level() 会退化成启动时快照；应传 Level: &runtimeLevel。
• 把 LevelVar 当成业务配置仓库：它只负责日志级别，不负责权限、审计和持久化。管理入口仍要做鉴权，并记录谁改了什么。
• 只看修改接口结果：必须补一条 Debug 和一条 Info 的实际输出检查，否则无法确认过滤器已经切换。

相关问题

LevelVar 和直接保存 slog.Level 有什么区别？

直接保存 slog.Level 适合启动时固定配置；需要运行时更新并让现有 Handler 立即看到变化时，使用 LevelVar 更合适。

LevelVar.Set 会让已经写出的日志重新出现吗？

不会。它只影响 Set 之后 Handler 做出的级别判断，已经被过滤或已经输出的记录不会被补写。

恢复 INFO 后如何确认服务真的恢复常态？

先读取 runtimeLevel.Level()，再分别产生 Debug 与 Info 记录，确认前者不可见、后者可见；不要只依赖管理接口的 HTTP 状态码。

最后的核对清单

把 *slog.LevelVar 放在日志组件的共享配置位置，HandlerOptions 直接引用它；外部文本先解析到局部 slog.Level，成功后再 Set；每次切换都用实际日志输出复查。这样动态调试和恢复常态都不会靠猜。