如何修复跨多包将日志器存入Context时触发的SA1029警告？

我之前也碰到过这个SA1029的警告，特别理解你这种纠结——既不想破坏context的解耦初衷，又要合规地在多包间传递日志器。先给你理清楚问题根源：SA1029警告是因为你用了内置类型string作为context的key，这种做法很容易导致不同包用相同的字符串key存不同的值，进而引发数据覆盖的问题。接下来给你两种实用的解决方案，还有对应的优劣分析：

方案一：在当前中间件包定义自定义类型的Context Key #

这是最直接的做法，不用额外新建包，只需要在你的middleware包内定义一个专属的context key类型：

// middleware/middleware.go
package middleware

import "context"

// 自定义context key类型，避免和其他包的key冲突
type contextKey string

// LoggerKey 用于在context中存储日志器的key
var LoggerKey = contextKey("logger")

然后在你的AuthMiddleware里用这个key存日志器：

func AuthMiddleware(logger *slog.Logger, userRepo repository.UserRepository, greetingUC *helloworld.HelloWorldUseCase) telebot.MiddlewareFunc {
    return func(next telebot.HandlerFunc) telebot.HandlerFunc {
        return func(c telebot.Context) error {
            requestID := rid.NewRequestID()
            log := logger.With("request_id", requestID)
            userTGID := c.Sender().ID
            log = log.With("telegram_id", userTGID, "telegram_username", c.Sender().Username)
            
            // 使用自定义的LoggerKey存入context
            ctx := context.WithValue(c.Context(), LoggerKey, log)
            // 更新context到telebot的上下文里
            c = c.WithContext(ctx)
            
            user, err := userRepo.FindByTelegramID(ctx, userTGID)
            // 后续逻辑...
            return next(c)
        }
    }
}

在repository包中，你只需要导入middleware包就能取出日志器：

// repository/user.go
package repository

import (
    "context"
    "your-project/middleware"
    "log/slog"
)

func (r *UserRepository) FindByTelegramID(ctx context.Context, tgID int64) (*User, error) {
    // 通过自定义key取出日志器，同时做类型断言校验
    log, ok := ctx.Value(middleware.LoggerKey).(*slog.Logger)
    if !ok {
        // 这里可以处理断言失败的情况，比如用默认日志器或者返回错误
        log = slog.Default()
    }
    
    log.Info("查找用户", "telegram_id", tgID)
    // 业务逻辑...
}

优缺点分析：

• 优点：实现简单，无需额外维护新包
• 缺点：repository包会直接依赖middleware包，如果后续项目迭代中middleware需要依赖repository，就会出现循环依赖的问题，只适合包依赖关系简单的小型项目

方案二：创建独立的共享Context Key包 #

如果你的项目规模较大，包之间的依赖关系复杂，推荐新建一个轻量的共享包来统一管理所有跨包使用的context key，彻底避免循环依赖的问题。

比如新建一个contextkeys包：

// contextkeys/keys.go
package contextkeys

import "context"

type contextKey string

// LoggerKey 跨包共享的日志器context key
var LoggerKey = contextKey("logger")

// 可以在这里添加其他跨包的context key，比如UserKey、RequestIDKey等

然后在middleware包中导入这个共享包来存日志器：

// middleware/middleware.go
import "your-project/contextkeys"

// ...中间件逻辑...
ctx := context.WithValue(c.Context(), contextkeys.LoggerKey, log)

在repository包中同样导入共享包来取日志器：

// repository/user.go
import "your-project/contextkeys"

// ...业务逻辑...
log, ok := ctx.Value(contextkeys.LoggerKey).(*slog.Logger)

甚至可以在共享包里封装一个工具函数，减少重复的类型断言代码：

// contextkeys/keys.go
import "log/slog"

func GetLogger(ctx context.Context) (*slog.Logger, bool) {
    log, ok := ctx.Value(LoggerKey).(*slog.Logger)
    return log, ok
}

这样其他包使用时只需要调用：

log, ok := contextkeys.GetLogger(ctx)

优缺点分析：

• 优点：彻底解耦各个业务包，所有跨包context key集中管理，规范统一
• 缺点：需要额外维护一个包，但这个包非常轻量，只负责定义key和工具函数，几乎没有维护成本

关于你顾虑的「共享包违背Context初衷」 #

其实Context的初衷是传递请求域的临时数据，而不是完全消除所有依赖。合理的共享key包是为了避免key冲突，让Context的使用更规范，完全符合设计初衷。只要这个共享包足够轻量，不包含业务逻辑，就不会带来任何问题。

内容来源于stack exchange