Go slog.Group 如何组织结构化日志字段：嵌套键与输出核对

日志里既要看到请求编号，又要把数据库操作放在自己的字段组里，直接把一长串键值对塞进 logger.Info 很快就会失去层次。slog.Group 的作用是把一组属性作为嵌套字段传给处理器；关键是先固定组名和字段顺序，再核对处理器真正写出的键。

slog.Group("request", "id", requestID) 会把后面的属性归到 request 组中；如果使用文本处理器，默认输出通常会以 request.id 这样的键展示，是否展开仍要以实际 handler 配置为准。

先把一条请求日志拆成两层

一个实际接口通常同时记录请求和存储操作。下面的 loadOrder 不连接真实数据库，只保留调用链，方便观察属性从函数参数进入日志处理器的路径。

package main

import (
    "log/slog"
    "os"
)

func loadOrder(logger *slog.Logger, requestID, orderID string) {
    logger.Info("order loaded",
        slog.Group("request", "id", requestID),
        slog.Group("storage", "table", "orders", "key", orderID),
    )
}

func main() {
    handler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{Level: slog.LevelInfo})
    logger := slog.New(handler)
    loadOrder(logger, "req-42", "order-7")
}

这里有三段真实路径：loadOrder 组织属性，slog.Group 生成两组嵌套属性，NewTextHandler 再把记录写到标准输出。图中只保留这些正文已经出现的节点，避免把日志采集器或不存在的中间层画进去。

组参数要按键值对核对

slog.Group 的可变参数仍然遵循属性列表规则：字符串键后面接对应值，接着再放下一组键值。把一个值漏掉，后续参数就可能被当成孤立属性处理，日志看起来像是字段错位。

logger.Info("order loaded",
    slog.Group("request",
        "id", requestID,
        "method", "GET",
    ),
    slog.Group("storage",
        "table", "orders",
        "key", orderID,
    ),
)

建议先把每个组单独排好，再合并到记录调用中。request.id、request.method、storage.table 和 storage.key 是这段代码中可直接核对的四个输出节点。

用最小输出检查处理器行为

不要只根据代码猜日志格式。保留上面的 HandlerOptions，在本地运行一次，让终端输出成为验收依据。重点看三件事：日志级别是否为 INFO，消息是否为 order loaded，以及组内字段是否带有稳定前缀。

go run .
# 预期核对：INFO 级别、order loaded 消息、request 与 storage 组内字段

不同处理器会采用不同的展示方式，JSON 处理器更适合被机器消费，文本处理器更适合人工排查。文章中的判断只依赖属性结构，不把某一种终端排版当成业务协议。

三个容易把日志写乱的细节

不要把组前缀和完整键名重复写

如果已经使用 slog.Group("request", "id", requestID)，就不要再额外写一个名为 request.id 的平铺属性。两者都可能出现在输出中，查询规则也会因处理器不同而变得难以统一。

不要把业务字段和组名混成一层

storage 表示数据路径，table 和 key 才是组内字段。以后增加 duration_ms 时，应该先判断它描述的是请求、存储还是整体记录，再放到对应层级。

不要跳过真实输出核对

改动处理器、级别或属性类型后，至少保留一条固定输入的日志样本。只看编译通过无法证明组名、字段名和最终展示方式满足下游检索约定。

把 slog.Group 留在清晰的边界内

当一组字段有共同语义时，用 slog.Group 表达层次；当字段只出现一次且没有共同前缀时，普通属性更直观。落地时可以从 loadOrder 这类小函数开始，先让 request 与 storage 两个组稳定下来，再根据查询习惯决定是否扩展字段。

最后的验收不是“代码能运行”这么简单：输入固定的 requestID 与 orderID，确认 request.id、storage.table、storage.key 都出现在预期处理器的记录里，并检查没有重复的平铺键。这样以后换成 JSON 输出或接入日志平台时，字段层次仍然清楚。

常见问题

slog.Group 能不能嵌套另一个 slog.Group？

可以继续组织层级，但应让每一层都有明确业务含义；层级过深会增加查询和阅读成本，先从一到两层开始核对。

文本输出和 JSON 输出的字段名一定一样吗？

不一定。属性语义相同，但排版和嵌套表现由具体 handler 决定，所以应在目标 handler 下保留一条可复现样例。

小结

slog.Group 解决的是结构化日志中的共同前缀和字段归属，不是自动替你设计日志规范。先在调用点划分 request、storage 等真实语义，再用最小输出核对处理器行为，日志才既方便人看，也方便后续检索。