Go slog 为什么没有输出上下文字段

如果 Go 的 slog 日志里只有 msg、level，却看不到请求 ID、用户 ID 等上下文字段，通常不是 JSON Handler 丢了数据，而是调用方式和 Handler 职责没有接上。slog.Info、logger.Info 这类无 Context 方法内部使用的是 context.Background()；即使换成 InfoContext，标准 Handler 也不会把 ctx.Value 中的所有值自动变成日志属性。

排查顺序是：先确认调用了 InfoContext 或 LogAttrs，再确认自定义 Handler 是否从传入的 Context 中读取了明确的字段，最后才检查 JSON 或文本格式化。

本文使用 Go 标准库 log/slog 的 Handler 链说明这个边界。示例只读取白名单里的请求 ID，不把整个 Context 序列化，也不依赖取消信号控制日志写入。

先看调用入口：Info 不会携带请求 Context

我第一次遇到这个现象时，先检查的是输出格式，后来才发现日志调用写成了 logger.Info("request finished")。这条调用没有参数位置可以接收请求 Context，Handler 收到的只能是默认上下文，因此它没有办法知道当前请求的 ID。

package main

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

func writeLog(ctx context.Context, logger *slog.Logger, out io.Writer) {
	// 无 Context 方法不能把 ctx 传给 Handler；out 只用于说明日志去向。
	logger.Info("无上下文字段")

	// 显式 Context 方法才会把请求上下文交给 Handler 链。
	logger.InfoContext(ctx, "携带请求上下文")
}

标准库文档把这两个入口明确分开：无 Context 的方法使用 context.Background()，而 InfoContext、Log 和 LogAttrs 接收调用方传入的 Context。这里的“携带”只表示 Handler 能拿到它，不表示字段已经自动出现在输出里。

Logger.With 解决的是固定属性，不是 Context 取值

Logger.With 很适合绑定每条日志都需要的稳定信息，例如服务名、组件名或实例区域。它返回一个带固定属性的新 Logger，但它不会扫描 context.Context，所以不能替代请求级字段提取。

// 固定属性属于 Logger；它们与请求 Context 是两条不同的来源。
logger := slog.NewJSONHandler(os.Stdout, nil)
appLogger := slog.New(logger).With(
	slog.String("service", "orders"),
	slog.String("component", "checkout"),
)

// requestID 仍然需要通过 InfoContext 交给 Handler。
appLogger.InfoContext(ctx, "订单已处理")

如果你的日志里能看到 service，却看不到 request_id，这通常说明 With 本身工作正常，缺的是“从 Context 选取字段并追加到 Record”的一层适配。

让自定义 Handler 读取白名单字段

slog.Handler 的 Enabled 和 Handle 都会收到 Context。可以在 Handler 外包一层，只读取约定好的键，复制 Record 后追加属性，再委托给 JSON 或文本 Handler。这样既能保留标准 Handler 的格式化能力，也不会把 Context 中无关的值、取消函数或内部对象写入日志。

package requestlog

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

// 使用私有键，避免不同包用同一个字符串键互相覆盖。
type requestIDKey struct{}

// ctxHandler 只负责把白名单字段转换为 slog 属性。
type ctxHandler struct {
	next slog.Handler
}

func (h *ctxHandler) Enabled(ctx context.Context, level slog.Level) bool {
	// 先委托级别判断，避免低级别日志提前读取上下文。
	return h.next.Enabled(ctx, level)
}

func (h *ctxHandler) Handle(ctx context.Context, record slog.Record) error {
	// Record 的属性可能与原记录共享状态，修改前必须先 Clone。
	record = record.Clone()
	if requestID, ok := ctx.Value(requestIDKey{}).(string); ok && requestID != "" {
		// 只输出明确允许的字段，不序列化整个 Context。
		record.AddAttrs(slog.String("request_id", requestID))
	}
	return h.next.Handle(ctx, record)
}

func (h *ctxHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
	// 保留 Handler 链，使 Logger.With 的固定属性继续生效。
	return &ctxHandler{next: h.next.WithAttrs(attrs)}
}

func (h *ctxHandler) WithGroup(name string) slog.Handler {
	// 保留分组语义，避免包装器破坏 WithGroup 的字段路径。
	return &ctxHandler{next: h.next.WithGroup(name)}
}

func NewLogger(out io.Writer) *slog.Logger {
	// JSON Handler 负责格式化，ctxHandler 负责补充请求字段。
	base := slog.NewJSONHandler(out, nil)
	return slog.New(&ctxHandler{next: base}).With(
		slog.String("service", "orders"),
	)
}

func WithRequestID(ctx context.Context, requestID string) context.Context {
	// 只把非敏感、可检索的请求标识放入 Context。
	return context.WithValue(ctx, requestIDKey{}, requestID)
}

调用时要同时满足两件事：把请求 ID 放入同一个 Context，并使用 InfoContext 或 LogAttrs。只做其中一件，输出仍可能缺字段。

// 传递同一个 ctx，Handler 才能读到 request_id。
ctx := WithRequestID(context.Background(), "req-7f31")
logger.InfoContext(ctx, "订单已处理", slog.Int("items", 3))

四个容易误判的边界

• 标准 Handler 不会猜字段。 Context 可以承载请求范围的数据，但哪些值应进入日志取决于应用的 Handler 或中间件约定。
• 键类型必须一致。 写入和读取要使用同一个私有键类型；不要一处用字符串键、另一处用自定义类型。
• 取消不等于不写日志。 slog 的 Handler 会拿到 Context，但 Context 被取消并不会自动阻止日志记录；是否输出由 Handler 的级别和实现决定。
• 不要把敏感信息放进日志。 请求 ID、租户标识等字段也应先做脱敏和长度约束，密码、令牌和完整用户对象不应通过 Context 自动导出。

如果仍然没有字段，可以按这个顺序定位：调用点是否真的使用 InfoContext；包装器是否被传给 slog.New；Handle 是否委托给下一个 Handler；字段是否为空或类型断言失败；最后再看输出格式是否隐藏了分组路径。

总结：把“传递 Context”和“输出字段”分成两件事

Go slog 没有输出上下文字段，最常见的原因不是 JSON 格式错误，而是把 Context 传递、字段提取和日志格式化混成了一步。无 Context 方法不会携带请求数据；InfoContext 只把 Context 交给 Handler；真正决定是否出现 request_id 的，是读取白名单字段并追加到 Record 的 Handler 逻辑。

相关问题：为什么 Logger.With 能输出 service 却不能输出 request_id？ 因为前者是 Logger 固定属性，后者需要从每次调用的 Context 读取。能否直接把 Context 转成 JSON？ 不建议，Context 的键和值没有通用序列化契约，也容易泄露内部数据。Handler 为什么要 Clone Record？ 因为 Record 的属性状态可能共享，修改副本可以避免影响原记录。