Go log/slog.Logger 怎样减少临时分配

我在把服务日志从格式化字符串改成结构化日志时，最先遇到的不是输出格式问题，而是高频日志路径里的临时工作：交替键值参数需要转换，稳定上下文被每条日志重复准备，低级别日志还可能在最终被丢弃后才发现前面的参数已经构造完。Go 的 log/slog 已经为这些场景提供了比较明确的路径。

减少 Go slog.Logger 临时分配的核心做法是：高频调用优先使用 LogAttrs 和 slog.String、slog.Int 等类型化 Attr；不会变化的字段在创建子 Logger 时用 With 提前处理；只有构造成本明显的参数，才在调用前用 Enabled 判断。普通日志不要为了追求一个想象中的数字而堆叠对象池，真正的收益要结合 Handler、输出 I/O 和自己的基准一起看。

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

如果只记一个优先级：先把“交替键值参数”改成“Attr 参数”，再把稳定字段移到 With，最后才考虑对昂贵参数做级别预判断。这样改动小，日志语义也比较容易保持不变。

LogAttrs 为什么更适合高频日志调用

Logger.Log 接受的是 ...any，它需要按照“字符串后跟值”的规则把参数转换成 Attr。Logger.LogAttrs 则只接受 Attr，调用路径更直接。官方文档也把 LogAttrs 定义为 Log 的更高效版本，适合已经明确知道字段类型的场景。

我会把两种写法分成“方便写”和“稳定热路径”两类。前者适合一次性日志、低频错误或字段还在快速变化的代码；后者适合循环、请求处理、队列消费等每秒调用次数明显的路径。下面的代码只展示输入形状，不代表固定的运行时分配数量。

package main

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

func writeLogs(ctx context.Context, logger *slog.Logger, userID int, route string) {
    // 交替键值写法可读，但 logger 需要先把 ...any 解释成 Attr。
    logger.Log(ctx, slog.LevelInfo, "request finished", "user_id", userID, "route", route)

    // 类型化 Attr 直接表达字段类型，热路径优先使用这一种形状。
    logger.LogAttrs(ctx, slog.LevelInfo, "request finished",
        slog.Int("user_id", userID),
        slog.String("route", route),
    )
}

func newDiscardLogger() *slog.Logger {
    // 这里用 io.Discard 隔离输出 I/O，便于把注意力放在调用形状上。
    handler := slog.NewTextHandler(io.Discard, &slog.HandlerOptions{Level: slog.LevelInfo})
    return slog.New(handler)
}

两种写法的最终字段可以相同，但第二种把“字段已经是 Attr”这个信息提前交给了 Logger。尤其是数字、布尔值和字符串，使用对应的构造器还能保留明确类型，不需要先把值塞进一个通用格式化字符串。

类型化 Attr 怎样减少不必要的转换

slog.String、slog.Int、slog.Bool 等构造器并不是为了让代码看起来更“专业”，而是让日志字段从创建开始就具有清晰的值类型。对常见数字和字符串，slog.Value 可以直接表示它们，不必先经过通用格式化。

因此，能确定类型时不要把所有内容都写成 fmt.Sprintf 的结果，也不要为了统一接口把每个值都包成复杂对象。日志字段后续还要被 Handler 编码、过滤或检索，保留类型通常比提前拼接文本更有用。

func logResult(logger *slog.Logger, jobID string, retry int, ok bool) {
    // 三个字段的类型在构造 Attr 时就固定下来，Handler 可以按字段类型处理。
    logger.LogAttrs(
        context.Background(),
        slog.LevelInfo,
        "job result",
        slog.String("job_id", jobID),
        slog.Int("retry", retry),
        slog.Bool("ok", ok),
    )
}

这不等于所有日志都必须改成 LogAttrs。低频错误日志更重要的是完整保留上下文和错误原因；如果为了少一次临时工作而牺牲可读性，收益通常不值得。优化应从真正的热点开始，而不是全局机械替换。

稳定上下文为什么适合交给 With

请求级日志通常有一组在同一请求内不会变化的字段，例如服务名、区域、请求 ID。把这些字段放在每一次 LogAttrs 调用里，既重复书写，也重复让 Handler 处理。Logger.With 会返回一个带有这些属性的新 Logger；底层 Handler 可以通过 WithAttrs 预先处理它们。

这里要注意“稳定”两个字：服务名、区域、请求 ID 往往稳定，当前 SQL、重试次数、返回码则可能变化。前者适合放进子 Logger，后者仍然应该在具体日志点传入，否则日志会记录成过期状态。

func requestLogger(base *slog.Logger, requestID string) *slog.Logger {
    // 子 Logger 在请求开始时创建一次，后续日志复用稳定的请求上下文。
    return base.With(
        slog.String("service", "checkout"),
        slog.String("request_id", requestID),
        slog.String("region", "cn-east"),
    )
}

func recordStep(logger *slog.Logger, step string, status int) {
    // step 和 status 会随调用变化，所以仍然放在当前事件中。
    logger.LogAttrs(
        context.Background(),
        slog.LevelInfo,
        "request step",
        slog.String("step", step),
        slog.Int("status", status),
    )
}

With 不是“把 Logger 放进池里”的意思。它更像是把稳定属性的准备时机从每一次日志调用，移动到了请求或组件初始化阶段。创建子 Logger 本身也有成本，所以不要在一个只打一条日志的短函数里层层调用 With；应让它的生命周期覆盖多次日志事件。

低级别日志什么时候值得先调用 Enabled

slog.Logger 在日志方法内部会先询问 Handler 是否启用当前级别。如果级别未启用，Logger 可以很早返回。但 Go 的函数参数求值发生在方法调用之前：如果你为了生成一个日志字段，已经做了昂贵的序列化、遍历或脱敏，那么 Logger 还没有机会替你跳过这段工作。

简单的 slog.Int、slog.String 不需要额外包一层判断；如果字段来自明显昂贵的计算，再考虑先调用 Enabled。预判断要和计算放在同一个条件块里，不能只判断级别却仍然在条件外构造参数。

func debugPayload(ctx context.Context, logger *slog.Logger, payload []byte) {
    // 只有构造调试字段成本较高时，才用 Enabled 避免无意义的计算。
    if !logger.Enabled(ctx, slog.LevelDebug) {
        return
    }

    // 这里假设摘要计算会遍历 payload，低级别关闭时就不执行它。
    summary := buildSummary(payload)
    logger.LogAttrs(ctx, slog.LevelDebug, "payload summary", slog.String("summary", summary))
}

func buildSummary(payload []byte) string {
    // 示例只表达成本边界，真实项目可替换为脱敏、序列化或摘要逻辑。
    return string(payload)
}

预判断也有边界：它会让代码多一次级别判断，普通字段并不会因此变得更快；如果 Handler 始终启用该级别，条件分支反而没有跳过任何工作。把它留给“被丢弃时真的能省下一段昂贵计算”的字段即可。

不要把 fmt.Sprintf 和对象池当成第一步

很多日志性能问题来自调用前的字符串拼接。比如先用 fmt.Sprintf 组装完整消息，再把结果交给 slog.Info，不仅失去结构化字段，还可能在日志级别关闭时白做拼接。更合适的做法是保留原始字段，让 Handler 在最终输出阶段编码。

func logHTTP(logger *slog.Logger, method, path string, status int) {
    // 不先拼接完整字符串，保留可检索的结构化字段。
    logger.LogAttrs(
        context.Background(),
        slog.LevelInfo,
        "http request",
        slog.String("method", method),
        slog.String("path", path),
        slog.Int("status", status),
    )
}

对象池也不是默认答案。日志事件的字段经常包含字符串、错误、切片或用户自定义值，强行复用容器容易把生命周期、并发访问和旧引用问题带进来。先使用官方 API 设计好的 Attr 和 Handler 路径，再用基准确认分配热点，通常比提前引入池更稳。

怎么判断优化是否值得

我会按三个问题做取舍：

1. 这条日志是否在循环、请求主路径或高并发消费者中高频出现？如果不是，先保证字段完整和代码清楚。
2. 当前成本来自参数转换、昂贵字段构造，还是 Handler 编码和输出 I/O？只改调用形状，不能解决后两者。
3. 稳定属性是否真的跨越多次日志事件复用？如果只使用一次，创建子 Logger 的成本可能没有必要。

可以为自己的 Logger 写一个小型 benchmark，分别比较交替键值、LogAttrs、带 With 的 LogAttrs，以及关闭 Debug 级别时的昂贵字段构造。重点观察 ns/op 和 allocs/op 的相对变化，不要把别人的数字直接当成当前服务的结论。

func BenchmarkLogAttrs(b *testing.B) {
    // 使用固定 Handler 和稳定输入，避免把测试对象的创建成本混进结果。
    logger := slog.New(slog.NewTextHandler(io.Discard, nil))
    ctx := context.Background()
    b.ReportAllocs()

    for i := 0; i 

常见问题

LogAttrs 一定比 Log 零分配吗？

不能这样绝对化。LogAttrs 避开了交替键值参数的转换路径，但 Handler、输出格式、时间和字段值本身仍可能产生工作。正确说法是：在相同 Handler 和相同字段下，它通常是更适合减少调用侧临时转换的入口，最终结果要以自己的基准为准。

把所有字段都放进 With 会更快吗？

只有跨多次日志调用且语义稳定的字段适合 With。变化字段放入 With 会造成过期上下文，单次日志使用 With 还可能把一次调用拆成子 Logger 创建和日志调用两段成本。

为什么已经关闭 Debug，昂贵的参数仍然被计算了？

因为参数在调用 Logger 方法前就已经求值。对昂贵计算使用 logger.Enabled(ctx, slog.LevelDebug) 包住计算和日志调用，才能在级别关闭时提前返回。

应该优先用 slog.Any 还是自己格式化？

优先保留结构化值，并根据字段是否稳定、是否昂贵、是否需要脱敏来选择 Attr 或 LogValuer。不要为了追求表面上的少一次调用而提前拼成字符串；那会削弱 Handler 的结构化处理能力。

减少日志分配后仍然很慢怎么办？

继续看 Handler 的编码、锁竞争、文件或网络写入，以及日志量本身。LogAttrs 主要改善调用侧的参数处理，不能代替输出链路的容量规划和采样策略。