GORM不能直接用于生产环境，因其默认行为与生产需求存在关键断层：AutoMigrate不加锁、不校验依赖、不支持回滚，易致锁表或数据错乱；连接池参数不合理会引发超时；软删除破坏唯一索引；预编译未开启拖慢高并发查询。
直接说结论：GORM不是“拿来就用”的ORM，它默认行为和生产环境需求之间存在几处关键断层，不主动干预就会在上线后暴露问题——比如软删除导致的唯一索引冲突、预编译未开启拖慢高并发查询、连接池参数不合理引发超时。
为什么 AutoMigrate 不能直接上生产
开发阶段用 AutoMigrate 看似省事，但它会执行 ALTER TABLE 操作，且不加锁、不校验依赖关系。线上表一旦有数据，迁移可能阻塞读写，甚至因字段类型变更（如 string → text）触发全表重建。
- 只在本地或测试环境启用
AutoMigrate，生产环境改用 SQL 迁移脚本 +db.Migrator().HasColumn()做前置检查 - 结构体新增字段带默认值时，
AutoMigrate不会自动填充历史数据，需额外执行UPDATE语句 - 如果模型用了
gorm.Model（含ID,CreatedAt等），但数据库已有同名字段且类型不匹配（如created_at是DATETIME而非TIMESTAMP），迁移会静默失败
Preload 和 Joins 到底该选哪个
两者都解决 N+1 查询，但语义和结果完全不同：Preload 执行多条 SQL（主查 + 关联查），返回嵌套结构；Joins 执行单条 JOIN 查询，返回扁平结果，且不支持反向关联（如从 Order 查 User 的地址）。
- 需要完整关联对象（如
User+ 其全部Orders+ 每个Order.Items）→ 用Preload，配合Limit和Order需放在主查询上 - 只需关联字段（如查订单列表并带上用户名）→ 用
Joins+Select，避免传输冗余数据 -
Preload在一对多场景下可能重复加载主表数据（N 条子记录 → N 次主表字段），此时应改用Joins+ 手动构造结构体
软删除（DeletedAt）的真实代价
GORM 默认启用软删除，所有 Find、First 查询自动加 WHERE deleted_at IS NULL。这看似安全，但会破坏唯一索引语义——例如用户邮箱字段设了 unique 约束，软删除一个邮箱为 a@b.com 的用户后，新用户仍能注册同邮箱，导致数据逻辑冲突。
- 业务上真正需要软删除的字段（如文章、评论）才加
gorm.DeletedAt，用户、订单等核心实体建议硬删除或归档到历史表 - 必须用软删除时，对唯一字段手动加复合索引：
UNIQUE INDEX idx_email_deleted (email, deleted_at)，确保已删除记录不影响新插入 - 查询时若需包含已删除数据，必须显式调用
Unscoped()，但要注意它会跳过所有 GORM 钩子（BeforeFind等）
MySQL 连接字符串里这三个参数不能少
光靠 user:pass@tcp(127.0.0.1:3306)/dbname 连不上生产 MySQL，尤其在容器化或跨时区部署时。
-
parseTime=True：否则time.Time字段会变成字符串，Where("created_at > ?", time.Now())直接失效 -
loc=Local：避免 MySQL 服务器时区与 Go 应用不一致，导致时间条件错位（如数据库存的是 UTC，应用按本地时区解析） -
timeout=5s（或readTimeout/writeTimeout）：防止网络抖动时连接卡死，GORM 默认不设超时，会一直 hang 住 goroutine
最常被忽略的其实是连接池生命周期管理——SetConnMaxLifetime 设得太长（如 24h），MySQL 侧连接空闲超时（默认 8h）后，Go 侧仍认为连接有效，下次复用就会报 invalid connection。这个坑往往在服务运行几天后才爆发。
