在Go Fiber项目中实现请求ID的全局日志追踪

背景介绍

在基于Go Fiber框架开发Web应用时，开发者经常需要在整个请求生命周期中追踪特定的请求标识（Request ID）。这种需求在微服务架构和分布式系统中尤为重要，能够帮助开发者快速定位和排查问题。

核心问题

当使用依赖注入方式管理日志组件时，如何在业务逻辑层（如handler或service）中获取并记录当前请求的ID，而不需要每次都显式传递Fiber上下文对象。

解决方案

方案一：中间件预处理

可以在中间件阶段将请求ID注入到日志组件中，这样后续业务逻辑可以直接使用预置了请求ID的日志实例。

app.Use(func(c *fiber.Ctx) error {
    // 从上下文中获取请求ID
    requestID := c.Get(fiber.HeaderXRequestID)
    
    // 为日志实例添加请求ID字段
    logger := sugarLogger.With(zap.String("requestID", requestID))
    
    // 将带有请求ID的日志实例存入上下文
    c.Locals("logger", logger)
    
    return c.Next()
})

方案二：自定义日志包装器

创建一个自定义的日志包装器，自动从Fiber上下文中提取请求ID。

type RequestAwareLogger struct {
    logger *zap.SugaredLogger
}

func (l *RequestAwareLogger) Info(c *fiber.Ctx, msg string) {
    requestID := c.Get(fiber.HeaderXRequestID)
    l.logger.With("requestID", requestID).Info(msg)
}

方案三：依赖注入扩展

如果使用依赖注入框架（如fx），可以创建一个工厂函数来生成带有请求上下文的日志实例。

func NewRequestLogger(c *fiber.Ctx, baseLogger *zap.SugaredLogger) *zap.SugaredLogger {
    requestID := c.Get(fiber.HeaderXRequestID)
    return baseLogger.With("requestID", requestID)
}

最佳实践建议

1. 一致性：在整个项目中保持统一的请求ID获取方式
2. 性能考虑：避免在每次日志调用时都重新创建日志实例
3. 可测试性：确保日志组件在测试环境下也能正常工作
4. 扩展性：设计应允许未来添加更多上下文信息

总结

在Go Fiber项目中实现请求ID的全局追踪有多种方式，开发者可以根据项目具体架构和需求选择最适合的方案。中间件预处理方案最为推荐，它既保持了代码的整洁性，又能确保请求ID在整个请求生命周期中的可用性。