租户标识应通过中间件从请求头、子域名或路径提取，并用context.WithValue注入Request.Context()，配合GetTenantID封装和租户感知DB/缓存设计实现完整隔离。
租户标识如何注入到 HTTP 请求生命周期中
Go 的 http.Handler 本身不携带租户上下文，必须显式传递。常见错误是把租户 ID 写死在全局变量或中间件外的闭包里，导致并发请求间互相污染。
正确做法是在中间件中从请求头（如 X-Tenant-ID）、子域名（tenant1.example.com）或路径前缀（/t/tenant1/api）提取租户标识，并通过 context.WithValue 注入到 Request.Context() 中：
func TenantMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(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
}
ctx := context.WithValue(r.Context(), "tenant_id", tenantID)
next.ServeHTTP(w, r.WithContext(ctx))
})
}- 不要用自定义类型做
context.Valuekey（易冲突），改用私有结构体字段或struct{}类型 - 避免在 handler 外直接读取
r.Context().Value("tenant_id")—— 应封装为GetTenantID(r.Context())函数，便于后期替换实现 - 若使用子域名解析，注意
net/http默认不解析 Host 中的端口，需手动strings.TrimPort(r.Host)
数据库连接如何按租户隔离
共享数据库 + 独立 Schema 或共享表 + 租户字段（tenant_id）是主流方案。前者隔离强但运维成本高；后者依赖严格 SQL 过滤，漏写 WHERE tenant_id = ? 就会越权读取。
推荐使用「租户感知」的 DB 查询封装，而非拼接 SQL 字符串：
type TenantDB struct {
db *sql.DB
}
func (t TenantDB) QueryRows(ctx context.Context, query string, args ...interface{}) (sql.Rows, error) {
tenantID, ok := GetTenantID(ctx)
if !ok {
return nil, errors.New("tenant ID missing in context")
}
// 自动追加租户过滤（仅适用于 WHERE 已存在的情况）
// 更安全的做法：所有查询走预定义语句，由 Repository 层强制注入 tenant_id
return t.db.QueryContext(ctx, query, append(args, tenantID)...)
}
- 禁止在 DAO 层直接调用
db.Query—
— 所有数据库访问必须经过带租户校验的 TenantDB实例 - PostgreSQL 可启用
row level security (RLS)，配合current_setting('app.tenant_id')实现内核级隔离 - 连接池不能跨租户复用：若用分库（每个租户独立 DB URL），需为每个租户维护独立
*sql.DB实例，避免SetMaxOpenConns误配影响其他租户
— 所有数据库访问必须经过带租户校验的 缓存键必须包含租户维度
Redis 或内存缓存中，user:123:profile 这类键名在多租户下是危险的 —— 不同租户可能有相同用户 ID，导致缓存污染或数据泄露。
所有缓存键应强制前置租户标识：
- 推荐格式：
tenant:{tenant_id}:user:{user_id}:profile - 避免用冒号嵌套过深，可考虑 base64 编码租户 ID 防止特殊字符干扰
- 使用
redis.Client时，不要共用 client 实例处理多个租户缓存 —— 虽然 Redis 本身无租户概念，但 key 命名混乱会导致FLUSHDB或KEYS *操作误伤 - 若用 Go 的
sync.Map做本地缓存，需为每个租户创建独立实例，或用map[string]*sync.Map按租户分片
goroutine 泄漏与租户资源清理
租户相关后台任务（如定时同步、事件监听）若未绑定租户上下文的取消信号，容易在租户停用后持续运行，消耗 CPU 和连接资源。
关键点在于：所有长期 goroutine 必须监听租户生命周期信号：
func startTenantSync(ctx context.Context, tenantID string) {
ticker := time.NewTicker(5 * time.Minute)
defer ticker.Stop()
for {
select {
case <-ticker.C:
syncDataForTenant(tenantID)
case <-ctx.Done(): // 租户被禁用或服务关闭
log.Printf("stopping sync for tenant %s", tenantID)
return
}
}}
- 租户停用时，应调用
context.CancelFunc主动终止其关联的所有 goroutine - 数据库连接、HTTP 客户端、gRPC 连接等资源，也需随租户上下文一并关闭 —— 别只关连接不 cancel context
- 用
pprof定期检查 goroutine 数量突增，特别关注含租户 ID 的协程名是否残留
租户隔离不是加个字段就完事的事。最常被忽略的是 context 传递的完整性 —— 一个中间件漏传、一个 goroutine 忘记 select ctx.Done()、一个缓存 key 少了 tenant 前缀，整套隔离就形同虚设。
