GORM 需正确初始化、模型定义和查询控制：gorm.Open 后必须检查 db.Error；启用 SkipDefaultTransaction；MySQL 连接加 parseTime=true&loc=Local；主键/时间戳需显式定义；批量操作用 CreateInBatches；Preload 深度勿超两层；调试必用 db.Debug()。
GORM 本身不是“加速开发”的银弹，它省的是手写 CRUD 的体力活，但用错方式反而拖慢迭代——关键在初始化、模型定义和查询链路的控制。
gorm.Open 之后必须检查 db.Error，不能只看 err 是否为 nil
GORM 的 gorm.Open 返回两个值：db *gorm.DB 和 err error。但很多场景下，连接参数写错（比如密码错误、数据库不存在）时，err 是 nil，而真实错误藏在 db.Error 里。不检查它，后续调用 AutoMigrate 或查询会 panic 或静默失败。
- 每次
gorm.Open后立即加if db.Error != nil { log.Fatal(db.Error) } - 使用
gorm.Config{SkipDefaultTransaction: true}避免隐式事务开销（尤其在 CLI 工具或批量导入场景） - MySQL 连接字符串中务必显式加上
parseTime=true&loc=Local，否则time.Time字段可能解析成零值
模型字段声明要区分 gorm.Model 和自定义主键/时间戳
直接嵌入 gorm.Model 看似省事，但它强制引入 ID uint、CreatedAt、UpdatedAt、DeletedAt 四个字段，且类型固定。实际项目里，主键常是 int64 或 string（如 UUID），时间字段也常需纳秒精度或独立命名。
- 用
type User struct { ID string `gorm:"primaryKey"` }显式控制主键 - 禁用默认时间戳：加
gorm.Model后再覆盖CreatedAt字段，或直接不嵌入，自己定义CreatedAt time.Time `gorm:"autoCreateTime"` -
gorm:"index"比gorm:"uniqueIndex"更常用；后者建唯一索引，但迁移时若数据已存在会失败
避免在循环里调用 db.Create，改用 db.CreateInBatches
逐条 Create 在插入百条以上记录时，性能断崖式下跌——每条都走一次 Prepare → Exec → Commit 流程。即使开了事务，GORM 默认仍对每个 Create 单独处理，无法真正批处理。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 批量插入用
db.CreateInBatches(users, 100)，第二个参数是每批数量，100 是 MySQL 的安全上限（受max_allowed_packet影响） - 注意：该方法不返回每条记录的
ID，如需回填主键，得用原生 SQL 或分页查新数据 - 更新同理，
db.Save是单条，db.Model(&User{}).Where("id IN ?", ids).Updates(map[string]interface{}{"status": "done"})才是批量
Preload 嵌套层级深时，小心 N+1 和笛卡尔积膨胀
Preload 看似自动关联，但二级预加载（如 Preload("Orders.Items")）会触发三次 JOIN 查询，若 Orders 有 10 条、每条 Items 平均 5 个，结果集就是 50 行，内存里却生成 10 个 Order 实例 + 50 个 Item 实例——重复数据全靠 GORM 去重，CPU 和 GC 压力陡增。
- 两层以内（如
User→Profile）用Preload安全；超过两层改用显式两次查询 + 内存关联 - 避免
Preload("Orders").Preload("Profiles")这种并列加载，它会生成 LEFT JOIN 多表，易因某张表无匹配行导致整行丢失 - 调试时加
db.Debug()看生成的 SQL，比猜更可靠
最易被忽略的其实是日志和错误传播：GORM 的 Error 字段不自动透传到上层，RowsAffected 在 Update/Delete 后必须手动检查，否则“以为删了 100 条”实际可能只删了 0 条。
