Go slog.Handler 怎样按级别筛选日志

Go 的 log/slog 按级别筛选日志，最简单的写法是给 TextHandler 或 JSONHandler 配置 HandlerOptions.Level；如果阈值需要按模块、上下文或运行状态变化，就让包装器实现 Handler.Enabled，把低于最低级别的记录尽早丢弃。

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

一、先看清 slog 的过滤位置

一条日志从 Logger 交给 Handler 后，先询问 Enabled(ctx, level)。只有返回 true，才会继续调用 Handle(ctx, record)。因此级别过滤应该放在 Enabled，而不是先把完整参数拼好，再在 Handle 里判断。

二、用 HandlerOptions.Level 做固定级别过滤

全局只需要一个最低级别时，不必先写包装器。HandlerOptions.Level 表示最低记录级别；没有显式设置时，处理器默认按 Info 级别工作。

package main

import (
	"log/slog"
	"os"
)

func main() {
	// 只输出 Warn 及以上级别，减少生产环境的低价值日志。
	logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
		Level: slog.LevelWarn,
	}))

	// Info 会在 Handler.Enabled 阶段被过滤，不会写入输出。
	logger.Info("忽略的运行信息")
	logger.Warn("需要关注的状态", "component", "api")
}

如果更偏好人类可读的文本，只需把构造函数换成 slog.NewTextHandler，级别判断仍由处理器完成。JSON 和文本处理器都遵循同一套最低级别语义。

三、用自定义 Handler.Enabled 封装策略

当阈值不是一个常量，例如某个模块需要比全局多输出一档，可以包装已有 Handler。关键是只改放行条件，其余行为继续交给底层处理器。

package main

import (
	"context"
	"log/slog"
)

// LevelHandler 在不改变输出格式的前提下增加最低级别。
type LevelHandler struct {
	level   slog.Leveler
	handler slog.Handler
}

// NewLevelHandler 保存动态级别对象，并复用已有 Handler 的输出逻辑。
func NewLevelHandler(level slog.Leveler, handler slog.Handler) *LevelHandler {
	return &LevelHandler{level: level, handler: handler}
}

// Enabled 要尽早判断，低于阈值的日志不会进入 Handle。
func (h *LevelHandler) Enabled(_ context.Context, level slog.Level) bool {
	return level >= h.level.Level()
}

// Handle 只负责转交，避免包装器重复实现格式化细节。
func (h *LevelHandler) Handle(ctx context.Context, record slog.Record) error {
	return h.handler.Handle(ctx, record)
}

// WithAttrs 必须返回带同一阈值的新包装器，保证链式 With 不丢策略。
func (h *LevelHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
	return NewLevelHandler(h.level, h.handler.WithAttrs(attrs))
}

// WithGroup 同样保留级别策略，并让底层处理器处理分组键。
func (h *LevelHandler) WithGroup(name string) slog.Handler {
	return NewLevelHandler(h.level, h.handler.WithGroup(name))
}

这个包装器的重点不是重写日志格式，而是把 Enabled 变成自己的策略入口。Handler 的方法可能被并发调用，所以若策略对象有可变状态，应使用 slog.LevelVar 或其它并发安全的状态容器。

四、用 LevelVar 实现运行期切换

排查线上问题时，常见需求是平时只记录 Warn，出现问题后临时打开 Debug。slog.LevelVar 实现了 Leveler，包装器每次判断时都能读取当前级别。

var programLevel slog.LevelVar

func newLogger() *slog.Logger {
	// 默认保留 Warn，后续可通过 programLevel.Set 调整。
	programLevel.Set(slog.LevelWarn)
	base := slog.NewTextHandler(os.Stdout, nil)
	return slog.New(NewLevelHandler(&programLevel, base))
}

func enableDebugForTroubleshooting() {
	// 排障结束后可恢复，避免 Debug 长期放大日志量。
	programLevel.Set(slog.LevelDebug)
}

如果只是标准处理器的固定阈值，直接使用 HandlerOptions{Level: &programLevel} 更简洁；自定义包装器适合还要叠加模块、租户或上下文判断的场景。

五、检查常见误区

1. 不要在 Handle 里才做级别过滤。那时记录已经通过了早期判断，调用方可能已经计算了昂贵参数。
2. 不要漏掉代理方法。只代理 Handle 而不代理 WithAttrs、WithGroup，会让链式 logger 丢失自定义阈值。
3. 不要误解 context。Enabled 可以读取上下文做决定，但 Handle 仍应把收到的 context 传给底层 Handler；取消 context 不应被当作停止记录的信号。
4. 不要把级别和输出格式混为一谈。Text、JSON 是编码选择，Level 是是否放行的选择，可以分别配置。

总结：按需求选择过滤层

相关问题

slog 默认会输出 Debug 吗？

通常不会。处理器的默认最低级别按 Info 处理；需要 Debug 时显式设置更低的级别或使用 LevelVar。

自定义 Handler 只实现 Enabled 可以吗？

不可以。Handler 还要求实现 Handle、WithAttrs 和 WithGroup；包装已有 Handler 时应把这些方法转交给底层。

为什么 Logger.Enabled 也值得调用？

当日志参数需要序列化、聚合或读取额外状态时，先判断能否输出，可以避免在记录最终被 Handler 丢弃前就付出计算成本。