Go log/slog Logger.Enabled 如何减少无效参数计算：级别判断与 Attr 构造边界

线上服务把日志级别从 Debug 调到 Info 后，CPU 还是没有明显下降，常见原因不是 Handler 失效，而是关闭的日志分支里仍然先算了大对象、拼了字符串，甚至构造了一串 Attr。Go 的 log/slog 提供了 Logger.Enabled，可以在这些工作发生前先问一句：当前级别是否真的会被处理。

把昂贵计算放在 Logger.Enabled 判断之后；已经是 slog.Attr 的轻量字段可直接交给 LogAttrs，不要为了“统一”而给每条日志都包一层检查。

Logger.Enabled 解决的是哪一段成本

Logger.Enabled(ctx, level) 本身不是日志输出开关的另一套实现，它会取得当前 Logger 的 Handler，再调用 Handler.Enabled。官方接口文档特别强调，这个判断会在参数被处理前发生，目的就是让被丢弃的日志少做无效工作。

因此要区分两类参数。slog.String("route", route) 只是在组装一个已知类型的 Attr，通常很轻；而 json.Marshal(payload)、遍历错误链或读取大量上下文，属于调用前就会发生的实际成本。

最小示例：先判断，再计算 expensiveValue

下面的 Handler 只接收 Info 及以上级别。expensiveValue 放在判断分支内，Debug 日志关闭时不会执行；Info 日志打开时则能看到完整结果。

package main

import (
	"context"
	"log/slog"
	"os"
)

func expensiveValue() string {
	// 这里模拟 JSON 编码、堆栈整理或大对象摘要。
	return "payload-summary"
}

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

	if logger.Enabled(context.Background(), slog.LevelDebug) {
		logger.Debug("debug details", slog.String("payload", expensiveValue()))
	}

	if logger.Enabled(context.Background(), slog.LevelInfo) {
		logger.Info("request accepted", slog.String("payload", expensiveValue()))
	}
}

运行后只会输出 request accepted。关键点不是 Debug 方法“自动优化”了 expensiveValue，而是第一段代码根本没有进入调用参数的计算路径。把函数调用直接写成 logger.Debug("debug details", slog.String("payload", expensiveValue()))，就无法依赖这层判断来阻止 Go 先求值。

什么时候用 LogAttrs，什么时候只用 Enabled

如果字段本来就是固定类型，LogAttrs 能让代码更直接：

attrs := []slog.Attr{
	slog.String("route", "/orders"),
	slog.Int("status", 200),
}

if logger.Enabled(ctx, slog.LevelDebug) {
	attrs = append(attrs, slog.String("payload", expensiveValue()))
	logger.LogAttrs(ctx, slog.LevelDebug, "debug details", attrs...)
}

这里把轻量字段放在判断外并不等于它们一定会输出，因为最终记录仍受 Handler 控制；判断外只适合那些构造代价明确很小、且不会暴露敏感内容的值。复杂字段、动态脱敏和大文本摘要应留在判断内。

自定义 Handler 的 Enabled 实现不能含糊

如果项目包了一层自定义 Handler，必须把级别语义传递清楚。最简单的做法是保存一个最小级别，并让 Enabled 比较当前级别：

type levelHandler struct {
	level slog.Level
	slog.Handler
}

func (h *levelHandler) Enabled(_ context.Context, level slog.Level) bool {
	return level >= h.level
}

包装 Handler 的 Handle、WithAttrs 和 WithGroup 仍要保持原有语义；只在 Enabled 返回值上做“全部放行”会让上层判断失去价值。使用 HandlerOptions{Level: ...} 时，也要确认最终挂到 Logger 上的是预期 Handler。

性能和安全边界：跳过计算不等于跳过审计

首先，Enabled 不是性能基准。它只能避免判断之后的工作，日志调用本身、级别判断和轻量 Attr 仍有成本，是否值得包判断要靠压测或 profile 证据。

其次，不能为了节省 Debug 成本把脱敏放到 Debug 分支之外，更不能把未经处理的令牌、Cookie 或用户隐私提前拼进字符串。对可能进入更高日志级别的字段，建议先确定字段白名单，再在需要时计算值。

• 大 JSON、堆栈和 SQL 计划：放在 Enabled 为真之后。
• 固定字符串、整数和布尔值：可直接用 slog.Attr 表达。
• 自定义 Handler：用测试分别验证 Debug 被丢弃、Info 被接收。

相关问题

Logger.Debug 会自动避免所有参数计算吗？

不会。Go 需要先求值函数调用参数；只有把昂贵计算放进 Enabled 为真的分支，才能明确跳过它。

Handler.Enabled 和 Logger.Enabled 有什么关系？

Logger.Enabled 是调用方入口，最终委托给当前 Handler 的 Enabled。自定义 Handler 的级别判断会直接影响上层结果。

所有日志都应该手写 Enabled 判断吗？

不应该。轻量字段直接记录更易读；只对序列化、复杂计算和明显的大对象处理做判断，并用 profile 验证收益。

小结

Logger.Enabled 的价值在于把“当前日志会不会被接收”提前变成一个可判断的条件。把 expensiveValue、大对象摘要和动态脱敏放到条件内部，再让 LogAttrs 承担已知类型字段的表达，代码既保留了 slog 的可读性，也不会在关闭级别上白白消耗资源。