Preload必须在db.Begin()之后、tx.Commit()之前调用，且需在事务对象tx上调用，否则关联查询脱离事务导致N+1和一致性破坏。
事务中Preload必须在Begin之后、Commit之前调用
很多人把 Preload 放在 db.Begin() 之前，以为“预加载配置”会自动继承到事务里——其实不会。GORM 的事务是全新会话，所有链式方法（包括 Preload）必须显式在事务对象上调用，否则主查询走事务，关联查询却走默认连接池，既破坏事务一致性，又可能触发 N+1。
常见错误写法：
db.Preload("Orders").Preload("Profile") // ❌ 这个Preload绑定的是db，不是tx
tx := db.Begin()
tx.Find(&users) // Orders/Profile 不会被预加载，循环访问时触发N+1
tx.Commit()
正确做法：
- 所有
Preload必须写在tx上，且在Find/First等执行方法之前 - 嵌套预加载如
Preload("Orders.Items")同样适用该规则 - 如果事务里要查多个模型，每个
Find都得单独配对应的Preload
事务内避免Where条件导致预加载失效
在事务中对预加载加 Where 条件时，容易误用作用域。比如写 tx.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid") })，看起来没问题，但若主查询本身带了 Where("deleted_at IS NULL")，而 Orders 表没有 deleted_at 字段，GORM 不会报错，而是静默跳过该预加载——最终还是退化成循环查。
关键判断点：
- 检查预加载子查询的
Where条件是否全部落在目标关联表字段上 - 用 SQL 日志确认预加载是否真生成了 IN 查询，而不是被忽略后 fallback 到懒加载
- 事务中建议开启
SlowThreshold，把预加载生成的 SQL 也纳入慢日志监控
事务里用Select控制字段，别让Preload加载整张表
事务场景下内存更敏感，尤其高并发写入时，Preload("Orders") 默认查 SELECT *，可能把几十个字段全捞进内存，不仅拖慢序列化，还放大 GC 压力。更糟的是，如果事务跨服务调用或含长事务逻辑，这些冗余数据会长时间驻留。
实操建议：
- 强制用
Select限定字段：tx.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Select("id, user_id, amount, status") }) - 避免在预加载里用
Omit，它不生效；Select是唯一可靠方式 - 如果只需要计数或某个字段，考虑改用
Count或原生子查询，比预加载更轻量
事务中嵌套Preload + Limit容易引发数据错位
这是最容易被忽略的坑：在事务里写 tx.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Limit(3) })，本意是每个用户只查最近 3 笔订单，但 GORM 实际执行的是「一次性查出所有用户的最多 3 笔订单」，不按用户分组。结果就是 A 用户可能拿到 0 条，B 用户拿到 3 条，C 用户拿到 2 条——总数 ≤ 3，而非每人 ≤ 3。
真正需要 per-user limit 时：
- 放弃
Preload，改用窗口函数 + 子查询（如 PostgreSQL 的ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)） - 或者事务外先查 ID 列表，再用
IN分批加载，手动做内存聚合 - 切记：GORM 的
Limit在预加载中不支持分组语义，文档没说，但源码里确实没实现
