GORM的gorm.DB实例不可跨微服务复用，因连接是进程级资源；每个微服务须独立初始化gorm.DB，启动时单次调用gorm.Open()并配置连接池参数、执行db.Ping()校验。
跨微服务连接复用根本不存在
GORM 的 *gorm.DB 实例无法、也不应跨进程（即跨微服务）复用。每个微服务必须持有自己独立的 *gorm.DB 实例，这是由 Go 进程隔离和 database/sql 连接池实现机制决定的——连接是操作系统级资源（文件描述符 + TCP socket），不能跨进程传递。
为什么有人误以为“可以复用”
常见混淆点来自以下几种情况：
- 把“共享 DSN 字符串”当成复用连接：多个服务用同一套数据库地址/账号，只是连了同一个 MySQL 实例，并非共享连接池
- 误用全局变量或配置中心同步 DSN：DSN 是配置，不是连接；每个服务仍会各自调用
gorm.Open()初始化自己的连接池 - 混淆 RPC 客户端复用和 DB 连接复用：比如
go-zero的rpcxclient可以预热并复用长连接，但那是 gRPC 层，和底层 MySQL 连接无关
真正要解决的是“如何避免重复创建连接池”
重点不是跨服务复用，而是单个服务内杜绝反复调用 gorm.Open()。否则会出现：
-
Too many connections：每次gorm.Open()都新建一个*sql.DB，旧池子不关，连接数指数增长 - 文件描述符耗尽：
cannot assign requested address错误频发 - 连接泄漏日志难排查：没有显式
db.Close()，进程退出前连接不会释放
正确做法：
- 服务启动时一次性初始化
*gorm.DB，通过包级变量或依赖注入容器（如wire/fx）注入到各 handler 或 service 结构体中 - 务必调用
db.DB().SetMaxOpenConns(120)、db.DB().SetMaxIdleConns(60)、db.DB().SetConnMaxLifetime(2 * time.Minute)，数值按 MySQLmax_connections值的 60%～80% 设置 - 初始化后立刻执行
db.Ping()，否则第一笔查询才建连，故障延后暴露
多服务共用数据库时的关键约束
当多个微服务都连同一个 MySQL 实例，唯一需要协调的是连接总数上限：
- 查 MySQL 当前限制：
SHOW VARIABLES LIKE 'max_connections'; - 假设返回
200，5 个服务就应合计控制在 ≤160 连接内（留余量给备份、监控等） - 每个服务单独配置
SetMaxOpenConns，例如均设为30，而非某个服务设100其他设10 - 不要试图用 “连接池代理” 或 “DB 中间件” 统一调度连接——这层抽象只会增加延迟和故障面，且违背 database/sql 设计哲学
连接池的本质是本地资源池化，它的“复用”只发生在单个 Go 进程内部。跨服务协调，只能靠配置收敛与容量规划，而不是技术上共享连接。
