多数据源必须使用独立的*gorm.db实例，每个数据源需单独调用gorm.open()并注册到全局map中，初始化顺序为配置加载→解析db-list→创建db→注册，yaml缩进和dsn时区等细节须严格规范。
多数据源必须用独立的 *gorm.DB 实例，不能共用一个全局变量
很多人误以为只要改 DB 的连接字符串就能切换库，结果所有操作都跑到同一个库上。Gin 本身不管理数据库，*gorm.DB 是 GORM 的实例，每个数据源必须持有自己独立的 *gorm.DB，否则事务、日志、连接池都会互相干扰。
常见错误现象：global.GetGlobalDBByDBName("test1") 返回 nil；或调用 MustGetGlobalDBByDBName panic 报 “no db found”；本质是没在启动时完成初始化或别名未注册。
- 每个数据源需单独调用
gorm.Open()，生成各自的*gorm.DB - 必须将这些实例存入 map 或结构体中（如
map[string]*gorm.DB），用alias-name作 key - 初始化顺序很重要：配置加载 → 解析
db-list→ 循环创建*gorm.DB→ 注册到全局容器 - 不要在 handler 里临时拼接 DSN 再
gorm.Open()，会泄漏连接、无法复用连接池
config.yaml 中 db-list 的 YAML 格式容易因缩进失效
YAML 对空格极其敏感，db-list 下每个数据库项必须以 - （破折号+一个空格）开头，且所有字段必须对齐到同一缩进层级。错一个空格，yaml.Unmarshal 就会静默忽略该条目，导致 alias-name 查不到。
典型问题：alias-name: "test1" 和 type: "mysql" 缩进不一致，或 disable: false 写成 disable:False（大小写敏感），都会让解析失败。
- 确保每项以
-开头，后面所有字段缩进 2 空格（推荐） -
disable必须是小写false或true，不能是False -
path和port分开写更安全，避免把127.0.0.1:3306塞进path导致解析出错 - 密码含特殊字符（如
@、/）时，整个dsn应由代码拼接并 URL encode，不要硬编码在 YAML 里
MySQL DSN 中 loc=Local 在容器或跨时区部署时会出错
本地开发时 loc=Local 没问题，但一旦部署到 Docker 或 Kubernetes，宿主机和容器时区不一致，Local 可能指向 UTC 或空时区，导致时间字段读写错乱，比如插入的时间比实际快 8 小时。
错误表现：数据库里存的是 2026-08-11 14:00:00，Go 读出来却是 2026-08-11 06:00:00 +0000 UTC；或者 time.Now() 插入后被转换成错误时区值。
- 生产环境统一用
loc=Asia/Shanghai（或其他目标时区），显式指定 - 避免用
parseTime=True却不配loc，否则 Go 会默认按 UTC 解析 - StarRocks 等兼容 MySQL 协议的引擎，DSN 参数也需同样处理，不能照搬 MySQL 示例
- 连接池参数如
max-open-conns应按单个库预估，别为所有库共用一套值
用 global.MustGetGlobalDBByDBName 前必须确保初始化已完成
这个函数会 panic，不是返回 error。它只适合在业务逻辑已确认 DB 可用的场景下使用，比如路由 handler 中。如果在 init 阶段、中间件初始化、或配置未加载完就调用，必然 crash。
真实踩坑点：有人把 global.MustGetGlobalDBByDBName("test1") 放在 init() 函数里，但此时 config.yaml 还没读取，map 为空，直接 panic。
- 启动流程应为：加载配置 → 构建并注册所有
*gorm.DB→ 启动 Gin server - handler 中优先用
global.GetGlobalDBByDBName(alias)判空，再处理 fallback 或报错 - 别在 middleware 初始化时就取 DB 实例，除非你明确控制了初始化顺序
- 单元测试里若 mock 多数据源，需手动调用注册函数，否则
MustGet一定失败
多个数据源之间没有自动事务协调能力，跨库更新必须靠应用层自己控制一致性，这点很容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
