当前位置：首页 > 文章列表 > Golang > Go问答 > Go 服务为什么该从 log.Printf 迁移到 slog：结构化字段、级别与采样边界

Go 服务为什么该从 log.Printf 迁移到 slog：结构化字段、级别与采样边界

来源：17golang原创 2026-08-11 16:38:02 0浏览收藏

线上接口出了慢请求，工程师通常先搜订单号、请求 ID 或租户名。若日志还是一整串格式化文本，字段一变，检索就要靠肉眼；Go 1.21 引入的 log/slog 正好把这些信息变成可过滤的键值字段，但它并不意味着所有 log.Printf 都要一次性重写。更稳妥的做法是先固定字段和级别，再逐个替换高价值日志。

要点速览

slog 的核心收益是字段可检索、级别可过滤，而不是单纯换一种输出格式。
请求级公共字段适合用 Logger.With 固定；高频路径要先判断级别，再构造昂贵属性。
迁移可以从入口层和错误日志开始，保留旧日志作为对照，最后再统一 Handler。

当一条请求日志里找不到真正的线索

假设接口日志长这样：

2026/08/11 15:20:41 update order=O-2719 tenant=acme cost=184ms err=timeout

人眼还能读懂，但日志平台不知道哪个片段是订单号，哪个片段是耗时。想按 tenant=acme 聚合时，应用可能还混用了 tenant_id、customer 两种叫法。问题不在文本输出本身，而在每个调用点都在临时拼装语义。

这里先别急着把全部旧代码替换掉。先选一条请求链，把请求 ID、业务动作、耗时和错误状态固定下来，再观察检索是否真的变简单。

Go 日志从一整串文本拆成 request_id、tenant 和 cost 字段，展示字段丢失如何阻碍检索

最小改法：先把 Handler 和公共字段定住

slog 把记录生成和输出格式分开。应用侧调用 Logger，Handler 决定写成文本还是 JSON。服务端通常从 JSON Handler 起步：

package main

import (
    "log/slog"
    "os"
)

func newLogger() *slog.Logger {
    options := &slog.HandlerOptions{Level: slog.LevelInfo}
    return slog.New(slog.NewJSONHandler(os.Stdout, options))
}

func recordRequest(logger *slog.Logger, requestID, tenant string, costMS int) {
    requestLogger := logger.With(
        slog.String("request_id", requestID),
        slog.String("tenant", tenant),
    )
    requestLogger.Info("order updated", slog.Int("cost_ms", costMS))
}

这段代码有两个值得保留的约束：公共字段只在请求边界绑定一次，单条事件只描述本次动作；字段名使用稳定的蛇形命名，避免同一个含义在不同包里反复改名。先运行一条成功和一条失败样本，确认日志平台能按 request_id、tenant、cost_ms 分组，再扩大范围。

级别不是装饰：它决定高峰期留下什么

slog 提供 Debug、Info、Warn、Error 等常用级别，也允许使用中间数值。生产环境把最低级别设为 Info 后，Debug 记录会被 Handler 丢弃，但调用点仍可能已经完成了昂贵的数据整理。

if logger.Enabled(ctx, slog.LevelDebug) {
    logger.DebugContext(ctx, "cache inspection",
        slog.String("key", buildCacheKey(order)),
        slog.Int("bytes", estimatePayload(order)),
    )
}

这里的检查点是：把昂贵的字段构造放到 Enabled 之后。普通字符串和整数不用过度优化，真正需要留意的是序列化大对象、拼接长文本和读取额外状态。不要因为“结构化日志更快”就默认所有日志都应该保留。