go http中间件应提取租户id并注入context：从x-tenant-id等安全来源获取，用私有key类型校验后存入context；dao层据此隔离查询，grpc需用拦截器透传；须严控context生命周期防泄露。
Go HTTP 中间件提取租户 ID 并注入 Context
租户 ID 通常来自请求头（如 X-Tenant-ID）、子域名或 JWT claim，不能靠 URL 路径硬编码。中间件是唯一合理位置——早于业务逻辑、晚于连接建立，且能统一拦截所有 HTTP 入口。
常见错误是直接在 handler 里解析 header 后赋值给全局变量或结构体字段，这会导致并发下租户 ID 混乱；或者用 context.WithValue 但 key 类型用 string，引发类型不安全和 key 冲突。
- 必须定义私有未导出的类型作 context key，例如
type tenantKey struct{}，避免与其他包 key 冲突 - 中间件中检查
r.Header.Get("X-Tenant-ID")是否为空，空则返回http.StatusUnauthorized，不往下传 - 租户 ID 建议做基础校验：非空、长度 ≤ 64、只含字母数字和短横线，防止后续 SQL 注入或日志污染
- 不要在中间件里做 DB 连接切换——那属于数据访问层职责，Context 只负责透传标识
数据库查询时如何安全使用 Context 中的租户 ID
Context 本身不操作数据库，它只是把租户 ID 安全带到 DAO 层。真正隔离靠的是查询语句加租户条件或连接池路由。强行用 context.Value 在 SQL 拼接中插入租户 ID 是高危操作，等同于手写 SQL 注入漏洞。
正确做法分两类：
立即学习“go语言免费学习笔记（深入）”；
- 共享数据库 + 表级隔离：所有查询自动补上
WHERE tenant_id = ?，参数从ctx.Value(tenantKey{})取，用sqlx.Named或gorm.Scopes封装通用条件 - 独立数据库/Schema：启动时按租户 ID 初始化
*sql.DB实例，缓存到sync.Map，key 为租户 ID；查询前从 Context 取 ID，再查 Map 拿对应 DB 实例 - 无论哪种，DAO 方法签名都应接收
ctx context.Context，而不是额外加tenantID string参数——否则调用方容易漏传或传错
gRPC 场景下 Context 透传租户 ID 的特殊处理
HTTP 中间件不适用于 gRPC，因为 gRPC 使用 metadata，不是 header。直接用 grpc.SendHeader 或 metadata.Pairs 传租户 ID 是对的，但服务端必须用 grpc.ServerOption 配合拦截器提取，不能依赖客户端“自觉”塞进 context.WithValue。
典型坑点：
- 客户端没调用
metadata.AppendToOutgoingContext(ctx, "tenant-id", id)，服务端就收不到，且无报错 - 服务端拦截器里用
metadata.FromIncomingContext取值后，必须再次用context.WithValue注入新 Context，否则下游 handler 拿不到 - gRPC 流式接口（stream）需在每个
RecvMsg前重新检查 metadata，因为流可能跨多个 RPC 周期 - 不要把租户 ID 存进 gRPC 的
Peer或TransportCredentials——它们跟认证强相关，不是业务上下文载体
Context 生命周期与租户 ID 泄露风险
Context 会随 goroutine 传播，一旦被长期 goroutine（比如后台定时任务、日志异步 flush）捕获，租户 ID 就可能误带到其他租户的上下文中。这不是 Context 设计缺陷，而是使用者没管好生命周期。
关键控制点：
- 永远不要用
context.Background()或context.TODO()启动一个带租户逻辑的 goroutine；应该用context.WithTimeout(parentCtx, ...)显式控制超时 - 异步任务（如发邮件、写审计日志）必须显式拷贝租户 ID 到任务结构体字段，而不是闭包捕获原始 Context
- 日志库若支持 context-aware（如
zerolog.Ctx(ctx)），优先用它；否则手动从 Context 提取租户 ID 加到日志字段，别依赖 logger 自动继承 - 第三方 SDK（如 opentelemetry、redis-go）若接受 Context，确认其内部是否可能缓存该 Context 并复用——有些老版本 client 会，导致租户 ID “粘滞”
租户 ID 不是越早塞进 Context 就越安全，而是要在最靠近入口处校验、最靠近出口处销毁。中间任何一层多一次 WithValue，就多一分泄漏可能。
