Go HTTP 服务如何用请求级依赖容器隔离租户配置：从全局变量到显式注入

多租户 HTTP 服务最容易留下的一类隐患，是把当前租户配置塞进全局变量：开发环境里请求看起来正常，一旦两个请求交错，A 租户的超时或数据源配置就可能被 B 租户读到。更稳妥的做法是让入口在每次请求开始时组装依赖，把它放进请求上下文，再由 Handler 沿调用链显式取出。

请求级依赖容器的重点不是“把所有东西都塞进 context”，而是只放本次请求必须共享、生命周期随请求结束的配置，并通过类型安全的访问函数交给下游。

先把租户配置的边界画清楚

示例服务只处理一个任务：根据请求头 X-Tenant-ID 选择租户的超时和数据源名称，并把配置交给业务处理函数。配置属于一次请求，不属于进程全局；处理器本身可以复用，但不能把当前租户写入共享字段。

这里借鉴的是 Go 对接口和 net/http.Handler 的轻量组合方式：服务依赖通过构造函数进入结构体，请求变化的数据沿 context.Context 传递。这样既不会制造一个“大而全”的容器，也不会让业务函数偷偷读取包级变量。

入口如何把依赖放进请求链

先定义配置和存储接口。示例中的 ConfigStore 只负责按租户查配置，真实项目可以用内存实现替换成数据库或配置中心；这正是接口带来的测试边界。

type TenantConfig struct {
    ID      string
    Timeout time.Duration
    Source  string
}

type ConfigStore interface {
    Find(ctx context.Context, tenantID string) (TenantConfig, error)
}

type Server struct {
    store ConfigStore
}

type tenantConfigKey struct{}

func withTenantConfig(ctx context.Context, cfg TenantConfig) context.Context {
    return context.WithValue(ctx, tenantConfigKey{}, cfg)
}

tenantConfigKey 使用私有类型，避免不同包用字符串键发生碰撞。入口从 X-Tenant-ID 取值，查到配置后创建子上下文，再把它交给 ServeHTTP。注意这里没有修改 Server 的字段，所以并发请求只共享只读的服务依赖。

Handler 怎样取出请求级配置

读取也集中在一个小函数里，避免业务代码到处写类型断言。缺少配置时直接返回错误，这个分支必须可见，不能用零值继续访问错误租户。

func tenantConfig(ctx context.Context) (TenantConfig, bool) {
    cfg, ok := ctx.Value(tenantConfigKey{}).(TenantConfig)
    return cfg, ok
}

func (s *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    tenantID := r.Header.Get("X-Tenant-ID")
    if tenantID == "" {
        http.Error(w, "missing X-Tenant-ID", http.StatusBadRequest)
        return
    }

    cfg, err := s.store.Find(r.Context(), tenantID)
    if err != nil {
        http.Error(w, "tenant config unavailable", http.StatusNotFound)
        return
    }

    ctx := withTenantConfig(r.Context(), cfg)
    r = r.WithContext(ctx)
    s.handleReport(w, r)
}

func (s *Server) handleReport(w http.ResponseWriter, r *http.Request) {
    cfg, ok := tenantConfig(r.Context())
    if !ok {
        http.Error(w, "tenant config missing", http.StatusInternalServerError)
        return
    }
    fmt.Fprintf(w, "tenant=%s source=%s timeout=%s", cfg.ID, cfg.Source, cfg.Timeout)
}

调用链很短，但边界明确：ServeHTTP 负责读取请求、查询 ConfigStore、调用 withTenantConfig；handleReport 只从当前请求的 Context 取 TenantConfig。从实现上看，r.Context().Value 承担的是按 tenantConfigKey 查值，而不是创建新的配置。当请求被取消时，后续存储查询也应继续使用同一个 r.Context()，让超时和取消信号沿链路生效。

哪些依赖不应该塞进 context

数据库连接池、HTTP 客户端、指标注册器和配置仓库都属于进程级依赖，应放在 Server 或下游服务结构体中，通过构造函数传入。把它们放进 context 会让依赖变成隐式的，测试时也不容易发现缺什么。

相反，租户 ID、请求截止时间、认证结果这类随请求变化、并且会沿调用链传递的值，才适合进入请求上下文。值一旦离开请求生命周期，就不应继续保存或异步使用。

从全局变量迁移时最容易踩的坑

• 只换存储位置，没有换生命周期：如果 TenantConfig 仍被某个全局 map 原地修改，context 只是包了一层旧问题；应在请求内拿到不可变副本。
• 用字符串当键："tenant-config" 可能和其他包冲突，私有键类型更稳。
• 缺失值静默降级：类型断言失败要返回可观察错误，不能拿空的 Source 继续请求。
• 把 context 存回 Server：请求上下文不能写入长生命周期结构体，也不要在请求结束后交给后台 goroutine 使用。

上线前用并发测试确认隔离

测试至少准备两个租户配置，让并发请求分别带上 X-Tenant-ID: tenant-a 与 X-Tenant-ID: tenant-b，重复运行并检查响应中的 tenant、source 和 timeout 是否始终成组出现。再运行 go test -race ./...，它能帮助发现仍然存在的共享写入；不过没有竞态报告也不等于租户逻辑一定正确，响应断言仍然要保留。

相关问题

为什么不直接把 TenantConfig 加到 Server 字段里？

Server 会被多个请求并发复用，当前租户配置放进去就成了共享可变状态；请求级值应留在请求链中。

context.WithValue 能替代依赖注入框架吗？

它只解决请求范围值的传递，不负责组装全部服务依赖。长生命周期组件仍应通过构造函数或结构体字段显式注入。

什么时候应该改成函数参数？

如果某个函数明确需要租户配置，而且调用链短，直接传 TenantConfig 更清楚；只有多个边界都需要同一请求元数据时，才考虑通过 context 传递。

把隐式共享状态改成可检查的边界

这次迁移真正改变的是生命周期：ConfigStore 和 Handler 仍是可复用的进程级对象，TenantConfig 则随请求创建、随请求结束。入口负责组装，业务函数负责使用，测试负责验证两条请求链没有串租户。边界一旦稳定，后续接入超时、认证和审计字段时，也能沿同一条请求链逐项检查。