Go log/slog以属性注入请求标识的日志组织方式

我在给 HTTP 服务补结构化日志时，最先遇到的不是输出格式，而是“同一个请求的几行日志对不上”。入口有 request_id，调用数据库和下游服务的函数却没有，排查一次请求只能靠时间和消息猜。Go 的 log/slog 更适合把这类字段绑定在请求级 logger 上：入口读取或生成标识，用 logger.With 注入，后面的函数只接收这个 logger 或从请求上下文取得它。

可靠的做法是把请求级 logger 当作一次请求的只读派生对象：每次请求单独创建，公共字段用 With 固定，局部字段仍在具体日志点追加；不要把 request_id 写进全局可变状态。

先把请求标识的边界定清楚

入口优先信任经过网关约束的 request_id；如果客户端值为空、过长或含有不可接受字符，就生成服务端标识。日志里还可以放 method、path 和 user_id，但密码、令牌、完整 Cookie 等字段不应因为“方便排查”而注入。

关键点是区分两条链：context.Context 负责截止时间、取消和请求范围的数据传递，*slog.Logger 负责输出结构化日志。把 logger 放入 context 可以减少函数参数，但不要用日志字段替代业务依赖，也不要把 logger 当作跨请求的缓存。

入口用 logger.With 绑定公共属性

下面的中间件展示一条完整边界：取得标识、创建派生 logger、交给 handler。With 返回新对象，原始 logger 仍可服务其他请求；JSONHandler 会把这些属性写成机器容易检索的字段。

package logctx

import (
	"context"
	"log/slog"
	"net/http"
	"strings"
)

type loggerKey struct{}

func WithRequestLogger(base *slog.Logger, next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 只接受简单标识，避免把整段用户输入直接写入日志。
		requestID := strings.TrimSpace(r.Header.Get("X-Request-ID"))
		if requestID == "" || len(requestID) > 96 {
			requestID = "generated-request-id" // 示例中用固定值，生产环境应换成随机 ID。
		}

		// With 派生请求级 logger，不修改 base，也不跨请求复用。
		logger := base.With(
			slog.Group("request", "id", requestID, "method", r.Method, "path", r.URL.Path),
		)
		ctx := context.WithValue(r.Context(), loggerKey{}, logger)
		next.ServeHTTP(w, r.WithContext(ctx))
	})
}

func LoggerFrom(ctx context.Context, fallback *slog.Logger) *slog.Logger {
	// 缺少请求 logger 时返回兜底对象，避免 nil logger 让错误处理再次失败。
	if logger, ok := ctx.Value(loggerKey{}).(*slog.Logger); ok {
		return logger
	}
	return fallback
}

用分组和 LogAttrs 保持字段可检索

字段少时可以直接追加 slog.String；服务变大后，建议把请求元数据和业务字段分组。WithGroup 会返回带命名空间的 logger，避免不同模块都使用 id 时相互覆盖。需要显式控制属性类型时，用 LogAttrs 比交替传入 key/value 更清晰。

func handleOrder(ctx context.Context, base *slog.Logger, orderID string) {
	logger := LoggerFrom(ctx, base).WithGroup("order")
	// LogAttrs 只接收 Attr，字段名和类型在调用点一目了然。
	logger.LogAttrs(ctx, slog.LevelInfo, "load order",
		slog.String("id", orderID),
		slog.String("stage", "repository"),
	)
}

如果 handler 已经拿到 context，优先使用 InfoContext、LogAttrs 等带 context 的方法。它让自定义 Handler 有机会读取 trace 等上下文信息，但不会自动把 context 中的每个值都打印出来。

并发与生命周期检查清单

还要留意 handler 的写入并发：内置 handler 会保证一条记录完整写出，但它不会替你做跨记录排序。日志采集系统应使用 request.id、trace_id 等字段关联，而不是依赖日志到达顺序。

常见问题

把 logger 放进 context 会不会破坏 context 的用途？

不会，但它只是工程上的依赖传递约定。截止时间、取消信号和业务值仍按 context 的原有规则处理，logger 不能替代它们。

为什么不直接用 slog.Default 加 request_id？

Default 是进程级入口，给单个请求追加属性会污染其他请求。请求级属性应使用 With 派生对象。

With 和每次日志都写 request_id 有什么取舍？

重复字段少、生命周期稳定时用 With 更易维护；只有一两条日志或字段会频繁变化时，局部追加更直观。