Go slog.Handler.Enabled 为什么会影响日志参数计算：级别判断、属性构造与性能边界

如果服务把日志级别设成 INFO，一条被过滤的 DEBUG 日志仍然在准备大对象、拼接长字符串，问题通常不在 Handler.Handle，而在调用点没有利用 slog.Handler.Enabled 的提前判断。slog.Logger 会先询问 Handler 是否处理这个级别，调用方可以把昂贵计算放在判断之后。

记住一条边界：Enabled 只负责“这条记录要不要交给 Handler”，不会自动阻止你在调用参数里提前执行的函数；想省成本，必须让昂贵工作发生在级别判断之后。

Logger.Debug 到底先调用了哪个方法

slog.Handler 是日志前端和输出后端之间的边界。slog.Logger 收到 Debug、Info 等调用后，会先用目标级别询问 Handler.Enabled；返回 false 时，记录不会继续交给 Handler.Handle。标准库源码和官方 Handler 指南都把这一步放在记录处理之前。

func emit(logger *slog.Logger, userID string) {
    logger.Debug("cache miss", "user_id", userID)
}

这里的 userID 已经是现成字符串，所以直接传递没有明显问题。真正容易踩坑的是把查询、序列化或大量格式化写进参数表达式；表达式会在进入 logger.Debug 之前求值，Handler 还没有机会替你取消这部分工作。

把昂贵字段放到级别判断之后

当调试日志需要读取请求快照时，先拿到 Handler，再调用 Enabled。下面的 buildSnapshot 只有在 DEBUG 级别确实打开时才会执行：

func debugSnapshot(ctx context.Context, logger *slog.Logger, orderID int64) {
    handler := logger.Handler()
    if !handler.Enabled(ctx, slog.LevelDebug) {
        return
    }

    snapshot := buildSnapshot(ctx, orderID)
    logger.DebugContext(ctx, "order snapshot", "order_id", orderID, "snapshot", snapshot)
}

这段写法的保护点是顺序：先做级别判断，再调用 buildSnapshot，最后才进入 DebugContext。如果团队封装了 DebugContext，也应让封装层提供类似的延迟入口，而不是先把快照作为普通参数算好。

自定义 Handler 时要守住两个契约

自定义 Handler 的 Enabled 至少要和 Handle 使用同一套级别边界。比如 Handler 配置最低级别为 slog.LevelInfo，那么 Enabled(ctx, slog.LevelDebug) 应返回 false；否则调用方会误以为调试日志会落盘。

type LevelHandler struct {
    min slog.Level
}

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

func (h *LevelHandler) Handle(_ context.Context, record slog.Record) error {
    // 输出 record，具体格式由 Handler 决定。
    return nil
}

第二个契约是不要把“是否启用”和“如何输出”混在一起。Enabled 只做便宜的判断；过滤器、采样器或动态级别组件若要读取共享状态，应控制锁和读取成本，避免每条日志都做与输出无关的重活。

三类参数该放在哪里计算

可以按成本简单分层。已经存在的字符串、整数和短键名直接传给 Logger；需要分配大对象、访问外部数据或进行序列化的值，放到级别判断后的分支内。不要为了追求“所有日志都极致优化”而把可读性很好的普通字段也包成复杂抽象。

• 低成本：orderID、状态值、固定消息，直接作为属性传入。
• 中成本：结构体转 slog.Group、大数组摘要，先确认级别再构造。
• 高成本：数据库查询、读取文件、请求外部服务，不能仅为日志触发；即使 DEBUG 开启，也要设置超时和失败处理。

怎么验证过滤真的发生了

不要只看控制台没有输出就下结论。给测试 Handler 增加计数，分别记录 Enabled 和 Handle 的调用次数，再调用一条低于最低级别的日志。期望是 Enabled 被询问，Handle 不被调用；把最低级别改低后，才应看到记录进入 Handle。

如果昂贵函数仍被调用，先检查它是不是写在 logger.Debug(...) 的参数表达式里；如果 Handle 次数不对，再检查自定义 Handler、包装 Handler 是否改变了级别判断。

相关问答

Enabled 返回 false 会不会丢掉 ERROR 日志？

只要 Handler 的最低级别配置正确，ERROR 通常高于 DEBUG 和 INFO，不会因为过滤 DEBUG 的判断而丢失。真正需要检查的是自定义级别映射是否写反。

能不能把所有日志字段都延迟构造？

不必。延迟判断本身也有代码成本，适合用于序列化、查询、文件读取和大对象构造；简单标量字段直接传入更清楚。

小结

Handler.Enabled 是日志记录进入后端前的级别闸门，不是参数求值器。理解 Logger.Debug、Enabled、Handle 的先后关系，再把真正昂贵的工作放到闸门之后，才能同时得到正确的过滤语义和可控的日志成本。