不能在Gin Group或路由注册时绑定数据库，因为Group和HandleFunc仅控制URL匹配与中间件顺序，不参与DB连接逻辑；正确做法是入口中间件解析租户标识、预加载并用sync.Map缓存租户专属*sql.DB实例，handler显式从context取值，读写分离由业务代码严格控制。
为什么不能在 Gin Group 或路由注册时绑定数据库
因为 Group 和 HandleFunc 只影响 URL 匹配与中间件执行顺序，完全不参与数据库连接逻辑。常见错误包括：
- 在
v1 := r.Group("/api/v1")里注册 handler，但代码仍用全局db *sql.DB，所有租户查的都是同一个库 - 以为
r.HandleFunc("/user/{id}", h).Methods("GET")能自动选 PostgreSQL 实例——它只提取路径参数，不触达 DB 初始化 - 把
tenantID放路径（如/t/abc123/users），中间件解析并塞进context，但 handler 忘了从ctx.Value(tenantDBKey)取值，继续用错库
根本问题在于：路由是 HTTP 层，数据库是数据访问层，二者必须正交。强行耦合会导致事务跨库、连接池争抢、缓存穿透等线上事故。
如何安全地预加载并缓存租户专属 *sql.DB
不要在 handler 里现场建连接，也不要用简单 map[string]*sql.DB——并发写会 panic，没健康检查，冷启动慢。推荐方案是：
- 用
sync.Map缓存已初始化的*sql.DB，键为租户标识（如 subdomain 或X-Tenant-ID） - 每个租户连接池单独调用
SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime - 连接串从主库（或 Vault / 加密配置）动态查出，避免硬编码密码
- 首次访问某租户时触发初始化，失败则返回 404 或 503，不 fallback 到默认库
示例关键逻辑：if db, ok := tenantDBCache.Load(tenantID); ok { return db.(*sql.DB) }，后续再做 lazy init。
立即学习“go语言免费学习笔记（深入）”；
入口中间件中如何正确注入租户 DB 到 context
必须在 Gin 中间件最前端完成 DB 注入，且确保 handler 不可能绕过。典型流程是：
- 从
r.Header.Get("X-Tenant-ID")或r.Host提取租户标识 - 校验格式（如正则匹配
^[a-z0-9]{4,32}$），非法直接c.AbortWithStatus(400) - 查主库
tenants表确认租户存在且状态为active - 调用缓存获取或新建租户
*sql.DB，失败则c.AbortWithStatus(503) - 用
c.Request = c.Request.WithContext(context.WithValue(c.Request.Context(), tenantDBKey, db))注入
注意：key 必须是私有变量（如 var tenantDBKey = struct{}{}），避免与其他包冲突；handler 内必须显式用 db := c.MustGet(tenantDBKey).(*sql.DB) 取值，不能依赖全局变量。
读写分离必须由业务 handler 显式控制
Go 没有“自动读写分离”的魔法，database/sql 本身不区分读/写连接。真实做法是：
- 每个租户缓存两个
*sql.DB：一个标为writeDB，一个标为readDB（指向从库） - 在 handler 里按操作类型决定用哪个：
writeDB.Exec(...)vsreadDB.QueryRow(...) - 事务必须全程使用
writeDB，且不能跨租户 DB 执行Begin() - 避免在
defer tx.Rollback()前意外 return，否则连接泄漏
最容易被忽略的是：事务内混用 readDB 与 writeDB，或者把 SELECT FOR UPDATE 发到从库——PostgreSQL 会报错 ERROR: cannot execute SELECT FOR UPDATE on a read-only transaction，MySQL 可能静默失败。
