Go http.Server.ConnContext 如何给连接绑定租户标识：握手阶段注入与请求读取边界

如果一个长连接上的每个请求都属于同一租户，把租户标识在连接建立时放进上下文，通常比每个处理器重复解析握手元数据更稳定。Go 的 http.Server.ConnContext 正好提供了这个入口：它接收新连接的基础上下文和连接对象，返回后续请求可继承的上下文。不过，连接级上下文只适合保存连接生命周期内不变的元数据，不能拿来代替请求认证或承载可变业务状态。

ConnContext 适合做“连接建立时注入、请求处理时读取”，真正的租户权限仍要在 ServeHTTP 或业务层再次核验，不能因为读到了一个上下文值就跳过认证。

先判断租户信息属于连接还是请求

这个问题通常出现在网关已经完成 TLS 或协议握手，后端服务又想在每个 Handler 里知道“这条连接来自哪个租户”的场景。比如内部代理在建立上游连接时写入租户标识，后续多个 HTTP 请求复用连接，服务端可以少做一次重复解析。

边界要先说清楚：连接级租户标识只在连接复用期间保持不变；如果同一连接允许不同用户或租户切换，租户就不能只靠 ConnContext 决定，而必须以每个请求的认证结果为准。把两种生命周期混在一起，是最容易出现串租户的地方。

用 ConnContext 在连接入口注入标识

示例先用一个固定的连接地址映射租户，方便把调用链跑通。真实服务通常会从受信任的代理协议、TLS 客户端证书或连接鉴权结果得到租户，不应直接相信任意请求头。

type tenantKey struct{}

func tenantContext(parent context.Context, tenantID string) context.Context {
    return context.WithValue(parent, tenantKey{}, tenantID)
}

func newServer(tenantByAddr map[string]string) *http.Server {
    return &http.Server{
        ConnContext: func(ctx context.Context, c net.Conn) context.Context {
            tenantID := tenantByAddr[c.RemoteAddr().String()]
            return tenantContext(ctx, tenantID)
        },
        Handler: http.HandlerFunc(handleRequest),
    }
}

ConnContext 的返回值会作为这条连接后续请求的上下文父节点。这里的 tenantKey 是私有空结构体类型，不会和其他包的字符串键碰撞；映射查不到租户时保留空字符串，后面由处理器显式拒绝，而不是把未知连接当成默认租户。

在 ServeHTTP 里读取并验证租户

读取逻辑集中在一个小函数中，业务处理器不需要到处写类型断言。即使上下文里已有租户标识，也要检查它是否为空；如果服务还要求请求级身份，就在这里继续验证请求凭据。

func tenantFromRequest(ctx context.Context) (string, bool) {
    tenantID, ok := ctx.Value(tenantKey{}).(string)
    return tenantID, ok && tenantID != ""
}

func handleRequest(w http.ResponseWriter, r *http.Request) {
    tenantID, ok := tenantFromRequest(r.Context())
    if !ok {
        http.Error(w, "tenant context missing", http.StatusForbidden)
        return
    }
    select {
    case 

这里的关键不是“能从 Context 取值”，而是把失败状态保留下来：tenantFromRequest 通过 r.Context().Value 找不到值时直接返回 403，取消信号出现时停止后续工作。这样排查日志时，可以区分“连接没有绑定租户”和“请求已经结束”两类问题。

哪些写法看似方便，实际会越过边界

• 把租户放到 Server 字段：Server 会被多个连接和请求共享，当前租户写进去后很容易互相覆盖。
• 用请求头覆盖连接上下文：如果请求头来自不受信任的客户端，它只能作为待验证输入，不能直接改变授权租户。
• 把可变配置塞进 Value：上下文值适合只读元数据；连接池、缓存客户端和配置仓库应通过结构体或构造函数注入。
• 让后台 goroutine 长期持有请求上下文：请求结束后上下文可能已经取消，异步任务应明确复制必要参数并拥有自己的生命周期。

用一个复用连接测试串租户风险

测试时不要只创建一次请求。先让一个客户端复用同一条 TCP 连接连续发送两个请求，再检查两个响应都读取了同一个连接级租户；随后另开一条连接，确认第二个租户不会覆盖第一条连接的值。

func TestTenantContextPerConnection(t *testing.T) {
    // 启动 httptest.Server 后，使用一个 http.Client 连续请求两次。
    // 断言同一连接返回同一个 tenant，另一连接返回不同 tenant。
    // 再用 go test -race ./... 检查 tenantByAddr 等共享映射没有并发写入。
}

如果连接地址映射会动态更新，不能一边请求一边普通写入 map；应在连接建立前准备只读快照，或者使用明确的同步方案。测试通过只说明当前边界成立，仍要把请求级认证和租户权限检查放在业务链路中。

相关问题

ConnContext 会对每个请求执行一次吗？

不会。它绑定的是新连接的上下文；同一连接上的多个请求会继承这份父上下文。

HTTP/2 连接能不能这样绑定租户？

可以绑定连接级元数据，但 HTTP/2 在一条连接上并发复用多个请求，不能据此替代每个请求的身份校验。

什么时候应该直接传函数参数？

如果只有一两个函数需要租户 ID，直接传参数更清楚；只有它需要沿多个请求处理边界传递且生命周期明确时，才考虑放入上下文。

把连接元数据和请求权限分开

ConnContext 解决的是连接建立时的上下文初始化，tenantFromRequest 解决的是处理器读取和失败分支。两者之间还隔着一层真正的认证授权。把这三件事拆开，既能利用连接复用减少重复工作，也不会把一个连接级字符串误当成完整的租户安全证明。