每个数据源必须是独立的sql.db或gorm.db实例，不能共享复用或靠use切库——硬切会导致事务丢失、连接耗尽、panic；mysql的use仅作用于单连接，而*sql.db是连接池抽象，无法保证操作落在同一库，事务和连接池参数均绑定实例级别。
Go 微服务里管理多数据源，核心就一条：每个数据源必须是独立的 *sql.DB 或 *gorm.DB 实例，不能共享、不能复用、不能靠 USE db_name 切库——硬切会丢事务、耗尽连接、甚至 panic。
为什么不能共用一个 *sql.DB 变量切换数据源
MySQL 的 USE 语句只影响单个连接的默认数据库，但 *sql.DB 是连接池抽象，每次 Query 可能拿到任意空闲连接，无法保证连续操作落在同一库；更关键的是，事务、连接超时、SetMaxOpenConns 等行为都绑定在实例级别，混用等于把 user 库的连接池参数套在 order 库上，流量高峰时一个库打爆，其他全卡死。
- 错误现象：
panic: sql: transaction has already been committed or rolled back或查询结果来自错误数据库 - 驱动不感知 DSN 变更：调用
db.Exec("USE other_db")后再db.QueryRow(...)，实际执行仍可能走原库（取决于连接池分配） - 事务完全失效：在
userDB.Begin()内调用logDB.Exec()，后者根本不参与该事务
如何初始化多个独立 DB 实例
显式创建、命名清晰、参数隔离。别写 var db *sql.DB 全局变量，也别在 func init() 里初始化——错误无法返回，服务启动失败难定位。
- 为每个数据源写专用工厂函数，例如：
NewUserDB(cfg Config) (*sql.DB, error)和NewOrderDB(cfg Config) (*sql.DB, error) - YAML 配置扁平化组织：
mysql.user_db.dsn、mysql.order_db.max_open_conns，避免嵌套导致解析复杂 - 每个实例必须单独调用：
userDB.SetMaxOpenConns(20)、orderDB.SetMaxOpenConns(50)，按业务负载差异化设置 - DSN 中特殊字符要编码：PostgreSQL 用户名含
@或密码含/，必须用url.QueryEscape处理，否则报pq: password authentication failed却密码正确
租户场景下如何动态加载数据源
不是所有租户都常驻内存。SaaS 类服务应按需初始化 + 缓存，避免启动时全量建连，也避免每次请求都重连。
- 用
sync.Map缓存：var tenantDBs = sync.Map{}，key 是租户 ID 字符串，value 是已初始化的*sql.DB - 中间件中从
r.Header.Get("X-Tenant-ID")提取标识，先查主库确认租户有效性，再查tenantDBs.Load(tenantID) - 未命中时调用
sql.Open初始化对应实例，并立即设置连接池参数，然后Store进 map - 注意：不要把
*sql.DB塞进context.WithValue后直接传给 handler——handler 应通过接口（如Queryer）接收，避免暴露底层驱动细节
聚合查询时如何安全并发拉取多源数据
串行查 MySQL、Redis、HTTP API 耗时累加；但盲目开 goroutine 容易漏错误或超时失控。重点不在“并发”，而在“可控并发”。
- 每个数据源封装成独立函数，接受
*sync.WaitGroup并在末尾调用wg.Done() - 为每个子请求单独套
context.WithTimeout：Redis 设 50ms，外部 HTTP 接口设 800ms，防止慢接口拖垮整体 - 用结构体字段收结果，别用
map[string]interface{}：类型安全、IDE 可跳转、JSON 序列化可控 - 错误必须区分临时性与业务性：
net.OpError或redis.Timeout属于可降级的 partial failure，而 JSON 解析失败或字段缺失才是真错误
最易被忽略的一点：事务跨数据源天然无效，GORM 的 Transaction() 或原生 sql.Tx 都只绑定单个实例。业务层若需要强一致性，得靠补偿逻辑，而不是幻想“统一事务”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
