不能在init()中初始化所有租户连接，因为会导致启动失败率飙升、资源浪费、无法应对租户动态增删，且任一租户db不可用即阻塞整个服务启动；正确做法是懒加载，结合主库预验、dsn安全构造、tenantdb.ping()验证及sync.map的loadorstore惰性初始化。
为什么不能直接在 init() 里初始化所有租户连接
init() 阶段就遍历 tenants 表、为每个租户调用 sql.Open，看似“一劳永逸”，实际会导致启动失败率飙升、资源浪费严重、且无法应对租户动态增删。更危险的是：某个租户 DB 服务暂时不可用，整个服务就卡在 init 阶段无法启动。
真正可行的做法是懒加载——只在第一个请求命中该租户时，才查主库、构造 DSN、调用 sql.Open 并完成健康检查。这要求：
- 主库
*sql.DB必须提前初始化并验证连通性（db.Ping()不可省） - 租户元数据（如
subdomain→db_name映射）必须能被快速查询，建议加索引 - DSN 构造逻辑要处理密码特殊字符（如
@、/），必须用url.QueryEscape编码 - 初始化后立即调用
tenantDB.Ping()，失败则记录错误、清理缓存、不写入sync.Map
如何用 sync.Map 安全缓存租户连接池
map[string]*sql.DB 在高并发下会 panic，而 sync.Map 虽线程安全，但不支持原子性“读-改-写”。常见错误是先 Load，再判断 nil 后 Store，中间可能被其他 goroutine 覆盖。
正确姿势是用 LoadOrStore，配合惰性初始化函数：
func (c *TenantDBCache) Get(tenantID string) (*sql.DB, error) {
if db, ok := c.cache.Load(tenantID); ok {
return db.(*sql.DB), nil
}
db, _ := c.cache.LoadOrStore(tenantID, c.initDB(tenantID))
return db.(*sql.DB), nil
}
注意：initDB 必须是纯函数（无副作用），且内部已做 db.Ping() 和连接池参数设置（SetMaxOpenConns、SetConnMaxLifetime）。别让 LoadOrStore 存一个未验证的连接。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
中间件里怎么把租户连接注入 context
别把 *sql.DB 直接塞进 context.WithValue——它不是 request-scoped 的值，而是租户级的长期资源。正确做法是注入租户标识（如 tenant_id），然后在 DAO 层按需从缓存取连接。
典型中间件逻辑：
- 从 Host 头提取 subdomain（如
acme.example.com→acme），或从 JWT claims 解析tenant_id - 校验该租户是否存在于主库（避免伪造 subdomain 导致缓存污染）
- 调用
tenantDBCache.Get(tenantID)获取连接，失败则返回 404 或 503 - 仅将
tenantID写入ctx：ctx = context.WithValue(ctx, tenantKey, tenantID)
DAO 层用这个 tenantID 去缓存查连接，而不是每次请求都重连或重复查主库。
GoLand 调试时容易忽略的连接泄漏点
在 GoLand 里单步调试多租户路由逻辑时，很容易漏掉两个关键动作：
- 没对每个租户
*sql.DB单独调用SetMaxOpenConns—— 如果只设了主库，租户库会沿用sql.DB默认的 0（不限制），导致 PostgreSQL 连接数爆满 - 没在程序退出前调用
tenantDB.Close()——sync.Map不会自动 Close，必须自己维护 shutdown hook，遍历缓存逐个 Close
更隐蔽的问题是：GoLand 的“Run with Coverage”模式会干扰连接池行为，某些版本下 db.Stats().OpenConnections 返回值异常。上线前务必在真实环境跑 go tool pprof 看连接数趋势，别信 IDE 里的调试数值。
