不能在Gin Handler里直接换数据库连接，因为sql.DB是全局复用的连接池，临时替换仅影响当前goroutine局部引用，无法同步至中间件或模型层，且并发修改会导致竞态和查询错库；正确做法是通过tenant_id透传，为每个租户预热/懒加载独立sql.DB实例并缓存，DAO层按需获取。
为什么不能在 Gin 的 Handler 里直接换数据库连接
因为 Go 的数据库连接池（*sql.DB）是全局复用的，不是每次请求新建的。你在 handler 里临时替换一个 *sql.DB 变量，只会影响当前 goroutine 的局部引用，不会改变其他地方（比如中间件、模型层）正在使用的连接池实例。更危险的是，如果多个请求并发修改同一个全局 *sql.DB 指针，会引发竞态，导致查询发到错误库甚至 panic。
推荐做法：把租户标识透传到数据访问层
核心思路是「连接池不变，查询路由变」——提前为每个租户初始化好独立的 *sql.DB 实例，存进 map；请求进来后解析租户参数（如 tenant_id 或子域名），查出对应 DB 实例，再传给 DAO 层。关键点：
-
tenant_id必须从可信来源获取：优先从 JWT payload 或已认证的 session 中取，避免直接信任 query/header 参数 - DB 实例 map 要用
sync.Map或读写锁保护，防止首次并发加载时重复建连 - 不要在 handler 里调
sql.Open，所有连接池应在启动时预热或按需懒加载并缓存
示例片段：
var dbMap sync.Map // key: tenantID, value: *sql.DB
func getDBByTenant(tenantID string) (*sql.DB, error) {
if db, ok := dbMap.Load(tenantID); ok {
return db.(*sql.DB), nil
}
// 懒加载：查配置 → sql.Open → 设置 SetMaxOpenConns 等
db, err := initTenantDB(tenantID)
if err != nil {
return nil, err
}
dbMap.Store(tenantID, db)
return db, nil
}
Gin 中如何安全提取并传递租户上下文
别用全局变量存当前租户 DB，用 Gin 的 c.Set() + 自定义中间件最稳妥。这样既隔离了请求生命周期，又避免跨 goroutine 误用：
- 中间件中解析租户标识（例如从
c.Param("tenant")或c.GetHeader("X-Tenant-ID")） - 调用
getDBByTenant()获取实例，存入 context：c.Set("db", db) - 后续 handler 或封装的 DAO 函数统一用
c.MustGet("db").(*sql.DB)拿连接 - 注意：
c.MustGet()会 panic，建议加类型断言检查
错误示范：c.Request.Context() 里塞 DB —— Gin 的 context 不保证跨中间件传递自定义值，c.Set() 才是官方支持方式。
容易被忽略的连接池泄漏和配置差异
每个租户 DB 连接池都得单独调优，否则小租户占满连接、大租户饿死：
- 不同租户的 QPS 差异大时，
SetMaxOpenConns不能全设成一样（比如统一 20），要按租户等级动态配 - 忘记调
SetConnMaxLifetime和SetMaxIdleConns，会导致底层连接僵死或频繁重建 - 租户 DB 切换后，事务必须显式绑定到当前 DB 实例，
tx, _ := db.Begin()里的db必须是本次请求的租户 DB，不能复用上个请求的
最麻烦的是迁移和监控：你得确保每个租户 DB 的 schema 版本一致，且 Prometheus 指标要按 tenant_id 打标签，不然根本分不清哪个库慢。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
