gorm.Open()仅创建gorm.DB实例并关联底层sql.DB，不初始化连接池；必须显式调用db.DB().SetMaxOpenConns()、SetMaxIdleConns()和SetConnMaxLifetime()配置连接池参数，否则高并发下易触发连接耗尽或超时错误。
gorm.Open() 本身不等于连接池初始化，只是返回一个可复用的 *gorm.DB 实例
很多人以为调用 gorm.Open() 就完成了连接池配置，其实它只负责创建 ORM 层对象，并自动关联底层 *sql.DB。真正的连接池行为由 *sql.DB 控制，而这个对象默认已启用连接池（最大打开数 0 = 无限制，空闲数 2，生命周期 0 = 永不过期），但这些默认值在生产环境极易出问题。
关键点在于：gorm.Config 完全不干预连接池参数；你必须通过 db.DB() 获取底层 *sql.DB 才能设置。
- 错误做法：只传
&gorm.Config{SkipDefaultTransaction: true}就以为万事大吉 - 正确路径：先
gorm.Open()，再调用db.DB().SetMaxOpenConns()等方法 - 漏掉这步 → 高并发时数据库被瞬间打满，报错
dial tcp: lookup xxx: no such host或too many connections
必须显式配置的三个 *sql.DB 连接池参数
不设这三项，等于没配连接池。它们和 GORM 自身配置完全无关，必须从 *gorm.DB 拿到 *sql.DB 后单独设置：
-
SetMaxOpenConns(n)：最大打开连接数。MySQL 默认是 1024，但 Go 应用通常设为 50–200 更稳妥（取决于 DB 实例规格） -
SetMaxIdleConns(n)：最大空闲连接数。建议 ≤SetMaxOpenConns，一般设为 20–50，避免空闲连接长期占着 DB 资源 -
SetConnMaxLifetime(time.Hour)：连接最长存活时间。强制连接定期重建，防止因网络抖动或 DB 侧超时导致的 stale connection（常见于云数据库）
示例代码片段：
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
if err != nil {
panic(err)
}
sqlDB, err := db.DB()
if err != nil {
panic(err)
}
sqlDB.SetMaxOpenConns(100)
sqlDB.SetMaxIdleConns(30)
sqlDB.SetConnMaxLifetime(time.Hour)
为什么不能重复调用 gorm.Open()？
每次调用 gorm.Open() 都会新建一个 *gorm.DB 实例，每个实例背后都绑着独立的 *sql.DB 连接池。如果在 handler 或 service 层反复调用，会导致：
- 连接池实例爆炸式增长，内存泄漏
- 每个池都尝试建连接，远超 DB 允许的最大连接数
- 日志里频繁出现
failed to connect database: dial tcp: i/o timeout
正确做法是全局只初始化一次，比如放在 init() 或依赖注入容器中，然后把 *gorm.DB 当作单例传入各模块。
DSN 中 parseTime 和 loc 参数影响时间字段解析
MySQL 时间类型（DATETIME / TIMESTAMP）在 Go 中映射为 time.Time，但若 DSN 缺少关键参数，会直接解析失败或变成零值：
- 必须加
parseTime=True，否则time.Time字段读出来是字符串或 panic - 必须加
loc=Local或loc=Asia/Shanghai，否则时间按 UTC 解析，存取不一致 - 错误 DSN 示例：
"user:pass@tcp(127.0.0.1:3306)/test"→ 缺少这两个参数，时间字段不可靠 - 正确写法：
"user:pass@tcp(127.0.0.1:3306)/test?parseTime=True&loc=Local"
这个细节不会报错，但会在业务逻辑中埋下隐蔽的时间偏移 bug，尤其涉及定时任务或数据比对场景。
