Preload带WHERE条件时主表记录不丢失，但关联数据为空是因未显式选择外键字段；正确写法需Select包含user_id等外键，多对多需手动JOIN目标表，条件函数内db上下文隔离需重写全部配置。
Preload 带 WHERE 条件时，主表记录会丢失未匹配关联项的行 —— 这不是 bug，是 LEFT JOIN 语义被隐式替换成 INNER JOIN 的结果。
Preload("Orders", "status = ?", "paid") 为什么漏掉没订单的用户
这个写法看似只过滤 Orders，实际生成的 SQL 是：SELECT * FROM orders WHERE user_id IN (?) AND status = 'paid'。问题不在这里，而在于 GORM 内部用的是 IN 子查询 + 单独 SELECT 关联表，它本身不丢数据；但如果你在 Preload 第二个参数里用了 db.Where 并且没显式 Select 外键字段，GORM 就无法把查到的 Order 绑定回对应的 User 上，user.Orders 会是空切片，看起来像“漏掉了”。
根本原因是：GORM 需要外键字段（如 user_id）才能做内存级关联映射。如果只 Select("id", "amount")，没有 user_id，就无法知道这条 Order 属于哪个 User。
- ✅ 正确写法必须显式包含外键或主键：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id", "user_id", "amount") }) - ❌ 错误写法（无外键）：
.Select("id", "amount")→user.Orders永远为空 - ⚠️ 注意：即使你用的是
Preload("Orders", "status = ?", "paid")这种字符串条件形式，GORM 仍会自动 SELECT 所有字段，所以外键总存在 —— 但它不支持复杂条件（比如 OR、子查询），此时必须用函数式写法
Preload 条件过滤后还要排序或分页？必须加 Limit
很多人写了 db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Order("created_at DESC") })，发现性能崩了。原因很简单：GORM 不会自动加 LIMIT，Order 单独存在时无效，它只是给后续的全量查询加了个排序，但数据还是全拉回来再内存排序。
- ✅ 要取最新 3 笔已支付订单：
.Order("created_at DESC").Limit(3) - ✅ 只判断是否存在已支付订单（不要数据）：
.Select("id").Limit(1)，比查全部字段快一个数量级 - ⚠️
Order单独出现 ≠ 生效；Limit缺失 = 全量加载，别信直觉
多对多预加载带条件时，中间表字段必须显式引用
比如 User 和 Role 是多对多，中间表叫 user_roles。你想预加载用户拥有的「激活态」角色：db.Preload("Roles", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "active") }) —— 这会报错或返回空，因为 status 在 roles 表，但 GORM 默认 JOIN 的是中间表，WHERE 实际作用在 user_roles 上，而它根本没有 status 字段。
- ✅ 正确做法是显式 JOIN roles 表：
db.Joins("JOIN roles ON roles.id = user_roles.role_id").Where("roles.status = ?", "active")，或者改用Joins("Roles")配合主查询条件 - ✅ 更稳妥的方式是放弃 Preload，改用
Joins("Roles").Where("roles.status = ?", "active")，再手动构造结构体（适合条件复杂场景） - ⚠️ 多对多不支持靠字段名自动推导关联条件，
Preload("Roles", "...")的 WHERE 永远作用在中间表，除非你手动干预 JOIN
最易忽略的一点：Preload 的条件函数里，db 是全新上下文，它不继承主查询的 Scopes、Joins 或 Table 设置。所有字段引用、表别名、权限控制逻辑，都得在函数体内重写一遍 —— 这不是封装缺陷，是设计上刻意隔离执行环境。
