闭包本身不感知租户id，正确做法是将其作为参数传入闭包返回的函数（如func(tenantid string) *sql.db），而非在定义时固化值；需配合带锁map或sync.map实现线程安全的惰性连接池缓存，并通过中间件解析tenantid透传，避免硬编码或并发冲突。
闭包怎么拿租户 ID 去选数据库连接
闭包本身不“知道”租户是谁，它只保存创建时捕获的变量。真正动态路由的关键，在于把租户标识（比如 tenantID）作为参数传入闭包返回的函数里，而不是在闭包定义时就固化某个值。
常见错误是写成这样：
func newRouter(dbMap map[string]*sql.DB) func() *sql.DB {
return func() *sql.DB {
return dbMap["default"] // 错！永远返回 default，没用到租户信息
}
}这根本不是多租户路由，只是个固定连接工厂。
- 正确做法：闭包封装的是「连接池映射表 + 路由逻辑」，实际调用时才传入
tenantID - 典型签名应为
func(tenantID string) *sql.DB，不是无参函数 - 如果租户 ID 来自 HTTP 请求头或 JWT payload，确保它在中间件里被解析并透传，别在闭包里硬编码
为什么不能直接用 map[string]*sql.DB 做路由表
看似简单，但直接用 map 存连接容易出并发问题和资源泄漏。Go 的 *sql.DB 本身是并发安全的连接池，但 map 读写不是。
更严重的是：没有连接健康检查，租户 DB 服务重启后，map 里还存着失效的 *sql.DB，后续查询会卡死或报 driver: bad connection。
- 必须加读写锁（
sync.RWMutex）保护 map，否则高并发下 panic 或数据错乱 - 要用
db.PingContext()定期探测连接有效性，失效时主动从 map 中清理 - 考虑用
sync.Map替代普通 map——但它不支持原子性删除+重建，仍需额外逻辑兜底
闭包里要不要初始化每个租户的 *sql.DB
不要。闭包初始化阶段就去连所有租户库，启动慢、失败难处理、且浪费资源。应该惰性初始化：第一次请求对应租户时，再建连接并缓存。
但要注意 race condition：两个 goroutine 同时查同一个 tenantID，都发现 map 里没有，然后都去新建连接，最后覆盖写入——白建一个。
- 用
sync.Once搭配临时存储（如map[string]*sync.Once）可解决，但管理复杂 - 更稳妥的是用
LoadOrStore配合sync.Map，但注意sync.Map的 value 类型必须是接口，需做类型断言 - 推荐组合：带锁的 map + 双检锁（double-checked locking）模式，先读，再锁内再读一次，再建
HTTP handler 里怎么安全调用这个路由函数
闭包生成的路由函数，本质是个“连接获取器”，它不该暴露给 handler 外部随意调用。必须绑定上下文生命周期，防止连接泄露或误用。
典型错误是在 handler 里直接 db := router("t123") 然后传给业务层——业务层可能缓存这个 *sql.DB，下次用时已过期。
- 路由函数返回的
*sql.DB应该只在当前请求作用域内使用，即 handler 内完成 query/tx - 若需事务，必须用
db.BeginTx(ctx, nil)，别用db.Begin()——后者不感知 context 超时 - 别把路由函数塞进 struct 字段长期持有；每次请求都应通过中间件注入 fresh 的
*sql.DB
