slog 日志级别动态修改后为何部分请求未生效

slog.LevelVar 在同一进程内是并发安全的，Set 后不需要等待“传播”。动态修改后只有部分请求生效，通常不是 LevelVar 可见性问题，而是这些请求经过了不同的 Logger 或 Handler：有的 Handler 持有同一个 *slog.LevelVar，有的保存了固定 slog.Level 快照；也可能是多实例部署只更新了一个进程。

先比较各请求实际使用的 Logger、Handler 和进程实例，再检查级别值。只要内置 Handler 的 HandlerOptions.Level 指向同一个 *slog.LevelVar，它就会在每条记录的 Enabled 判断中读取最新阈值。

官方文档：https://pkg.go.dev/log/slog

影响面：为什么看起来像“部分请求没生效”

一个典型现象是：管理接口把级别从 INFO 改成 DEBUG 后，新进入的部分 HTTP 请求出现调试日志，另一些请求仍然只有 INFO；后台任务也可能完全没有变化。由于同一时间既有成功又有失败，排查方向很容易落到缓存、CPU 可见性或请求并发上。

但 LevelVar 内部使用原子读写，官方文档明确说明它可以被多个 goroutine 安全读写。真正值得关注的是 Logger 所有权：请求 A 可能使用全局默认 Logger，请求 B 使用中间件在启动时保存的 Logger，后台任务又由单独构造的 Logger 处理。三者名字都叫 logger，却不一定共享 Handler，更不一定共享 LevelVar。

时间线：先区分“值没变”还是“路径不同”

不要先加 sleep。可以在控制接口修改前后，对每个已知 Logger 调用 Enabled。它只检查指定级别是否会被处理，不会真正写一条日志，适合做低成本探针。

func debugState(ctx context.Context, name string, logger *slog.Logger) {
	// Enabled 直接询问当前 Handler，避免用“有没有输出”间接猜测。
	slog.Info("logger level probe",
		"logger", name,
		"debug_enabled", logger.Enabled(ctx, slog.LevelDebug),
		"info_enabled", logger.Enabled(ctx, slog.LevelInfo),
	)
}

// 分别检查默认 Logger 与依赖注入 Logger，结果不同就说明路径已分叉。
debugState(ctx, "default", slog.Default())
debugState(ctx, "request", requestLogger)
debugState(ctx, "worker", workerLogger)

如果同一个 Logger 在 Set 前返回 false、Set 后立即返回 true，LevelVar 已正常工作；仍不输出时，再检查记录是否经过另一个包装 Handler、是否被采样或是否写到了不同输出。若三个 Logger 的探针结果不同，问题已经从“并发可见性”缩小为“Logger/Handler 配置不一致”。

根因一：Handler 没有共享同一个 LevelVar

HandlerOptions.Level 接受 slog.Leveler。传入具体的 slog.LevelInfo 会固定阈值；传入 *slog.LevelVar 才能动态读取。如果构造 Handler 时调用了 runtimeLevel.Level()，保存的只是当时的 Level 数值，后续再对 LevelVar 调用 Set 不会影响它。

var runtimeLevel slog.LevelVar

// 错误：Level() 在构造时取出固定值，Handler 不再引用 runtimeLevel。
fixedHandler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
	Level: runtimeLevel.Level(),
})
fixedLogger := slog.New(fixedHandler)

// 正确：直接传入同一个指针，Handler 每条记录都会读取当前级别。
dynamicHandler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
	Level: &runtimeLevel,
})
dynamicLogger := slog.New(dynamicHandler)

runtimeLevel.Set(slog.LevelDebug)

// dynamicLogger 会放行 DEBUG，fixedLogger 仍保持构造时的 INFO 阈值。
dynamicLogger.Debug("dynamic logger changed")
fixedLogger.Debug("fixed logger is still filtered")

更隐蔽的情况是，每个模块都创建了自己的 new(slog.LevelVar)。它们初始值都是 INFO，看起来配置相同，但管理接口只修改其中一个指针。解决办法是让应用配置层拥有唯一 LevelVar，并把该指针注入所有需要联动的 Handler；不要在各模块内部重复创建。

触发条件：替换默认 Logger 不会改掉旧 Logger

slog.SetDefault 会替换之后由顶层 slog.Info、slog.Debug 等函数使用的默认 Logger，但已经保存到结构体、请求上下文或闭包中的 *slog.Logger 仍指向原来的 Handler。运行中同时“换 Logger”和“改 LevelVar”时，很容易形成两套配置。

建议只在程序初始化阶段构造 Logger 和设置默认值，运行时仅修改共享 LevelVar。依赖注入可以传递同一个 Logger 指针，也可以创建带固定属性的派生 Logger；logger.With(...) 和 WithGroup(...) 会派生 Handler，但内置 Handler 仍共享同一个 Leveler 配置。

type Logging struct {
	Level  *slog.LevelVar
	Logger *slog.Logger
}

func NewLogging(out io.Writer) *Logging {
	level := new(slog.LevelVar) // 零值为 INFO，只创建一次并由配置层持有。
	handler := slog.NewJSONHandler(out, &slog.HandlerOptions{Level: level})
	logger := slog.New(handler)
	slog.SetDefault(logger)
	return &Logging{Level: level, Logger: logger}
}

func (l *Logging) SetLevel(text string) error {
	var level slog.Level
	// 使用标准解析逻辑，拒绝未知级别，避免静默回退到 INFO。
	if err := level.UnmarshalText([]byte(text)); err != nil {
		return fmt.Errorf("parse slog level %q: %w", text, err)
	}
	l.Level.Set(level)
	return nil
}

func (l *Logging) RequestLogger(requestID string) *slog.Logger {
	// 派生 Logger 只增加属性，底层 Handler 仍读取同一个 LevelVar。
	return l.Logger.With(slog.String("request_id", requestID))
}

根因二：双重过滤或多实例只更新了一部分

自定义包装 Handler 经常再做一次级别判断。如果外层动态阈值已降到 DEBUG，但底层 JSONHandler 仍固定在 INFO，记录还是会被底层拒绝。多个过滤层的实际结果是“最严格的一层生效”，外层放宽无法恢复已经被内层过滤的记录。

type LevelHandler struct {
	level slog.Leveler
	next  slog.Handler
}

func (h *LevelHandler) Enabled(ctx context.Context, level slog.Level) bool {
	// 两层都必须放行；底层若固定为 INFO，DEBUG 仍然无法通过。
	return level >= h.level.Level() && h.next.Enabled(ctx, level)
}

func (h *LevelHandler) Handle(ctx context.Context, r slog.Record) error {
	return h.next.Handle(ctx, r)
}

func (h *LevelHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
	// 派生 Handler 继续共享同一个动态 Leveler。
	return &LevelHandler{level: h.level, next: h.next.WithAttrs(attrs)}
}

func (h *LevelHandler) WithGroup(name string) slog.Handler {
	return &LevelHandler{level: h.level, next: h.next.WithGroup(name)}
}

最简单的修复通常是只保留一层动态过滤：直接把共享 LevelVar 交给内置 Handler。必须包装时，底层阈值要设置得足够宽，或让内外层读取同一 Leveler，并用测试确认组合结果。

在容器、副本或多进程部署中，LevelVar 只是进程内变量。管理请求命中实例 A 后，实例 B 的 LevelVar 不会自动变化；负载均衡继续把业务请求分配到两个实例，于是用户观察到“有时生效、有时不生效”。这时需要通过配置中心、广播通道或逐实例管理接口更新全部副本，并给变更携带配置版本。

另一个容易混淆的入口：标准 log 桥接

项目若同时使用 log.Printf 和 slog，还要注意 slog.SetLogLoggerLevel。它控制标准 log 与 slog 默认 Logger 之间的桥接级别，不等同于 HandlerOptions.Level。修改共享 LevelVar 只改变 Handler 的最低阈值，不会自动改写桥接记录使用的级别。

排查时应把日志调用来源写清楚：是 slog.Debug、某个显式 Logger 的 DebugContext，还是旧代码里的 log.Printf。三者最终可能进入同一输出，但前置级别语义不同。

修复动作：用一个所有者管理动态级别

1. 应用启动时创建唯一 *slog.LevelVar，由配置组件持有。
2. 所有需要同步变化的 Handler 都直接引用这一个指针，不传 Level() 快照。
3. 避免运行时替换整棵 Logger；只修改 LevelVar，并为派生 Logger 保留统一来源。
4. 若存在包装 Handler，逐层检查 Enabled，确认没有固定阈值继续拦截。
5. 多实例更新返回实例 ID、当前级别和配置版本，未确认的实例不能算成功。

防复发：测试可见性而不是只看文本输出

最小测试应直接断言 Enabled：初始 INFO 时 Debug 为 false，调用 Set(DEBUG) 后同一个 Logger 与所有派生 Logger 都变为 true。另加一组测试证明旧 Logger 或固定 Level Handler 不会被误认为动态配置。并发测试可以在多个 goroutine 里交替读取 Enabled 和调用 Set，配合 Go race detector 检查自定义包装状态。

线上建议为每条日志附带稳定的 logger_scope 或配置版本，而不是记录内存地址。管理接口展示每个实例的当前级别、版本和更新时间。这样下次出现部分请求缺少 Debug 日志时，可以先按实例与 Logger 来源分组，不再从“LevelVar 是否延迟生效”开始猜。

相关问题

LevelVar.Set 后需要加锁或 sleep 吗？

不需要。LevelVar 自身使用并发安全的原子读写；同一进程内共享同一指针时，问题不在额外等待。

把级别设置成 ERROR 为什么日志更少了？

slog 的级别数值越高表示越严重，HandlerOptions.Level 是最低阈值。设为 ERROR 会过滤 DEBUG、INFO 和 WARN，不是“输出更多错误细节”。

logger.With 创建的 Logger 会继续动态更新吗？

内置 Handler 的派生实例仍沿用原有 Leveler，因此只要最初传入的是同一个 *LevelVar，就会读取更新后的值。

为什么同一实例里后台任务仍没变化？

检查后台任务是否在初始化时保存了另一套 Logger、固定 Level，或经过额外包装 Handler。用 Enabled 探针分别测试最直接。

参考资料

• Go log/slog：https://pkg.go.dev/log/slog
• Go slog 包说明源码：https://go.dev/src/log/slog/doc.go
• Go HandlerOptions 源码：https://go.dev/src/log/slog/handler.go
• Go 默认 Logger 与 log 桥接源码：https://go.dev/src/log/slog/logger.go