gorm.open 仅初始化配置并返回 db 实例，真实连接在首次查询/写入时建立；需正确导入驱动（如 "gorm.io/driver/mysql"）并传 mysql.open(dsn)；dsn 必须含 parsetime=true、loc=local 等关键参数；连接池需通过 db.db() 手动设置。
gorm.Open 不会立即建立真实数据库连接，它只初始化配置并返回一个 DB 实例；真正建连发生在首次执行查询（如 db.First）、写入或事务操作时。
gorm.Open 的参数顺序和驱动导入必须匹配
- GORM v2 要求第一个参数是 驱动的
Open函数调用结果，不是字符串驱动名（v1 写法已废弃） - 必须显式导入对应驱动包，且不能只靠
_导入：GORM v2 不再自动扫描匿名导入的驱动 - 常见错误：
failed to initialize database, got error: driver: unknown driver "mysql" (forgotten import?)
无序列表：
- ✅ 正确导入：
import "gorm.io/driver/mysql"，然后传mysql.Open(dsn) - ❌ 错误写法：
gorm.Open("mysql", dsn)（v1 风格，v2 不支持） - ❌ 驱动未导入或拼写错误（比如写成
import "gorm.io/driver/MySQL"，大小写敏感）
示例：
import (
"gorm.io/gorm"
"gorm.io/driver/mysql"
)
<p>dsn := "user:pass@tcp(127.0.0.1:3306)/test?charset=utf8mb4&parseTime=True&loc=Local"
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
</p>
DSN 中关键参数影响连接行为和时区处理
DSN 字符串里几个参数不单是“能连上”，还决定时间解析、超时控制和字符集兼容性：
-
parseTime=True：必须开启，否则time.Time字段会读成字符串或零值 -
loc=Local：让 MySQL 返回本地时区时间（避免 UTC 和系统时区错位），若服务部署在 Docker 或跨时区环境，建议显式设为loc=Asia%2FShanghai -
timeout=1000ms：控制 TCP 连接建立超时（不是 SQL 执行超时），默认无限制，生产环境应设上限 -
readTimeout/writeTimeout：需在 DSN 中额外指定，否则依赖底层net.Conn默认值（通常很长）
无序列表：
- 缺少
parseTime=True→CreatedAt字段反序列化失败，值为零时间 -
loc=UTC但应用逻辑按本地时间比对 → 时间字段看起来“慢 8 小时” - DSN 里没设
timeout→ 网络抖动或 DB 宕机时，gorm.Open可能卡住几十秒才报错
连接池配置必须通过 *gorm.DB 对象设置，而非 DSN
gorm.Open 返回的 DB 实际包装了 *sql.DB，但连接池参数（如最大空闲、最大打开数）无法在 DSN 里配置，必须手动调用方法设置：
-
db.SQLDB()获取底层*sql.DB，再调用其SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime - GORM v2 没有内置连接池参数透传机制，漏掉这步 = 用默认值（
MaxOpenConns=0，即不限制，可能耗尽 DB 连接数）
无序列表：
- 生产环境建议：
SetMaxOpenConns(20)、SetMaxIdleConns(10)、SetConnMaxLifetime(time.Hour) - 不调用
db.SQLDB()→ 连接池始终使用database/sql默认策略（MaxIdleConns=2，极易成为瓶颈） -
SetConnMaxLifetime过短（如 5 分钟）→ 频繁新建连接，增加握手开销
示例：
sqlDB, err := db.DB()
if err != nil {
panic(err)
}
sqlDB.SetMaxOpenConns(20)
sqlDB.SetMaxIdleConns(10)
sqlDB.SetConnMaxLifetime(time.Hour)
真正建立物理连接的时机、DSN 参数语义、连接池控制这三点，最容易被跳过或想当然。尤其在容器化部署中，loc 和 timeout 配置错误会导致日志里查不到错，但时间字段全乱或请求偶发超时。
