Preload的WHERE条件只过滤关联数据，不筛选主表；要筛选主表需用Joins+Where，并注意去重和字段冲突。
关联查询时 WHERE 条件不生效？先确认 Preload 的加载时机
GORM 的 Preload 默认只负责加载关联数据，**不会把 WHERE 条件下推到 JOIN 子查询里**。比如你写 db.Preload("Orders", db.Where("status = ?", "paid")).Find(&users)，看起来像要查“已支付订单”，但实际执行的 SQL 里，WHERE status = 'paid' 只作用于 orders 表的独立 SELECT，而主查询 users 仍返回全部用户——哪怕某些用户根本没符合条件的订单。
真正想实现“只查有已支付订单的用户”，得用 Joins + Where，而不是依赖 Preload 的条件过滤。
用 Joins 实现带条件的关联筛选（推荐）
这是最直接、可控的方式：显式 JOIN 关联表，并在 WHERE 或 ON 中加条件。注意两点：一是 GORM v2 默认不自动去重，可能因一对多产生重复主记录；二是需手动指定 SELECT 字段避免字段冲突。
- 用
Joins("JOIN orders ON orders.user_id = users.id")显式关联 - 用
Where("orders.status = ?", "paid")筛选关联行（这会过滤掉无匹配订单的用户） - 加
Distinct()避免同一用户因多笔订单被重复返回 - 若需同时查出订单数据，得用
Scan(&result)接收结构体切片，不能直接Find(&users)
type UserWithPaidOrder struct {
ID uint
Name string
OrderID uint
OrderNo string
Status string
}
var results []UserWithPaidOrder
db.Joins("JOIN orders ON orders.user_id = users.id").
Where("orders.status = ?", "paid").
Distinct().
Select("users.id, users.name, orders.id as order_id, orders.order_no, orders.status").
Find(&results)
Preload + Where 的真实用途：加载子集，而非筛选主表
当你确实需要“所有用户”，但只加载他们各自的“已支付订单”时，Preload 加条件才合适。此时 GORM 会发两条 SQL：一条查 users，一条用 IN 子句查匹配的 orders（带 WHERE 条件）。
立即学习“go语言免费学习笔记（深入）”；
- 条件只影响预加载的关联数据量，不影响主表结果集大小
- 确保关联字段（如
user_id）有索引，否则 IN 查询可能变慢 - GORM v2.2+ 支持
Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid") })，更清晰
错误用法：db.Where("orders.status = ?", "paid").Preload("Orders").Find(&users) —— 这里 Where 引用的是未 JOIN 的 orders 表，会报 invalid field found for struct 错误。
嵌套关联筛选容易漏掉外键约束
比如查“用户 → 订单 → 订单项中 price > 100 的商品”，用 Preload("Orders.Items", db.Where("price > ?", 100)) 是可行的，但要注意：
- 中间表（如
orders）必须能通过外键链路正确关联，GORM 不会自动推导缺失的 JOIN 条件 - 若
Items属于Order，而Order的 foreign key 字段名不是默认的order_id，需在 struct tag 里明确foreignKey:"OrderID" - 嵌套 Preload 的 WHERE 条件无法控制主表或中间表的筛选逻辑，纯属“加载时过滤”
真正要筛出“至少有一个高价商品的用户”，还是得回到 Joins 多层 JOIN + Where 的写法，且每层 JOIN 都得手动写清楚连接条件。
关联筛选的核心分歧点在于：你要的是“主表数据的子集”，还是“主表全量 + 关联数据的子集”。选错方式，SQL 就会偏离预期，而且 debug 时不容易从日志里一眼看出 JOIN 是否发生、条件是否下推。
