GORM事务复用底层*sql.DB连接池，需在事务前配置SetMaxOpenConns等参数；设太小导致排队超时，设太大引发MySQL连接数爆满；多数据源须单独配置，且配完应调Ping验证。
事务本身不拥有独立连接池——GORM 的事务复用的是底层 *sql.DB 连接池里的连接，所以「事务连接池参数」这个说法是误导性的。真正要配的，是事务所依赖的那个 *sql.DB 实例的连接池参数，且必须在事务开始前就配好。
为什么 db.Transaction() 会卡住或超时
事务阻塞通常不是事务逻辑问题，而是连接池没水了：当 SetMaxOpenConns 太小（比如设成 5），而并发事务请求超过 5 个，后续事务就会在 Begin() 阶段排队等连接，表现为 P99 延迟陡增、甚至 context deadline exceeded。
-
db.Transaction()内部会先从池里取一个连接，再执行BEGIN；如果池空了，它就卡在获取连接这步 - 默认
SetMaxOpenConns=0（无上限）看似安全，但 MySQL 侧max_connections是硬限制，Go 侧不设上限等于把爆库风险全甩给 DB - 事务中嵌套调用其他 service 方法时，若那些方法也用了
db.Transaction()，可能重复争抢同一池连接，加剧排队
SetMaxOpenConns 和事务并发量怎么对齐
别按“每个事务需要 1 个连接”线性估算。真实压力来自峰值并发事务数 + 非事务查询（如健康检查、日志写入）+ 其他服务共享 DB 的余量。
- 查 MySQL 当前上限：
SHOW VARIABLES LIKE 'max_connections';，假设返回200 - 生产推荐值：
SetMaxOpenConns = 120～160（即 60%～80%），留出空间给备份、监控、慢查询积压 - 云数据库（如阿里云 RDS）更保守：按 CPU 核数 × 20 估算，4 核实例建议设
80而非拍脑袋150 - 设太低（如
10）会导致 20 并发事务直接排队；设太高（如500）则 MySQL 很快报Too many connections
SetMaxIdleConns 和 SetConnMaxLifetime 对事务的影响
这两个参数不直接影响事务语义，但决定事务能否稳定拿到“活连接”。空闲连接过期或被中间件静默断开后，事务 Begin() 可能拿到一个已失效连接，首次执行 SQL 时报 read: connection reset by peer 或 i/o timeout。
- 必须先设
SetMaxOpenConns，再设SetMaxIdleConns（值 ≤ 前者），否则 Go 运行时 panic：max idle conns exceeds max open conns - 推荐组合：
SetMaxIdleConns = SetMaxOpenConns × 0.5（例如开 100，空闲留 50） -
SetConnMaxLifetime设为 2～5 分钟（云环境选 2 分钟），比 MySQL 的wait_timeout小 5～10 分钟，强制连接到期释放，避免事务复用僵死连接 -
db.Ping()不能代替SetConnMaxLifetime：它只验证初始化那一刻的连通性，不保活也不清理池中闲置坏连接
多数据源下事务连接池容易漏配的点
用 dbresolver 或多个 *gorm.DB 实例时，每个数据源的连接池参数必须单独配置——共用一个 SetMaxOpenConns 调用，只生效于调用它的那个 *sql.DB。
- 主库
userDB和从库replicaDB是两个独立连接池，userDB.DB().SetMaxOpenConns(100)不影响replicaDB - 事务只绑定单个
*gorm.DB实例：userDB.Transaction()里调logDB.Create()，后者完全游离在事务外，且走自己的连接池 - 别在
func init()里配连接池：失败无法返回 error，日志里只留一句 “DB initialized”，实际连接参数全是默认值 - 使用依赖注入（如 fx/wire）时，给每个 DB 绑定唯一类型别名，例如
type UserDB *gorm.DB，否则容器会混淆实例
最常被跳过的一步是：配完所有参数后，没调 db.Session(&gorm.Session{}).Ping()（GORM v2）。连接池参数生效了，但第一笔事务仍可能因 DNS、密码、网络问题当场失败——这不是参数问题，是验证缺失。
