Preload分页会查出远超预期的关联数据，因先查主表再用IN批量查关联表，无法限制每个用户的子项数量；Joins分页返回扁平结果且不填充嵌套结构体，需手动处理字段映射与游标逻辑。
Preload 分页时会查出远超预期的关联数据
分页场景下用 Preload("Orders")，GORM 会先执行 SELECT * FROM users LIMIT 20 OFFSET 0，再拿这 20 个用户的 ID 去查所有匹配订单：SELECT * FROM orders WHERE user_id IN (1,2,...,20)。如果其中某个用户有 500 条订单，那这次预加载就拉回 500 条，而不是“每个用户只取最新 3 条”。
常见错误现象：接口响应时间忽高忽低、内存占用飙升、返回 JSON 体积暴涨；调试时打开 db.Debug() 能看到第二条 SQL 的 IN 列表和结果行数完全失控。
- 想限制每个用户的订单数量？
Preload本身不支持，得换思路：用子查询或窗口函数（需数据库支持），或改用Joins+ 手动去重聚合 - 分页总数统计不能复用带
Preload的 DB 实例，Count()不会触发预加载逻辑，但也不会自动带上关联条件——它只扫主表 - 若必须用
Preload分页，至少加Order("created_at DESC").Limit(3)在预加载内部（见下一条）
Joins 分页返回扁平结果，结构体字段永远为空
db.Joins("Orders").Find(&users) 看似简洁，但 users[0].Orders 一定是空切片。因为 JOIN 后的结果是多行扁平记录（1 用户 × 3 订单 = 3 行），GORM 不做嵌套赋值，只按字段名映射到 User 结构体上。
使用场景有限：仅当你需要主表+关联表几列做聚合统计（如 SELECT users.name, COUNT(orders.id)），且不依赖 Order 结构体方法或验证时才适用。
- 要让
Joins返回可用数据，必须用Select()明确字段，并定义接收结构体（不能复用User） -
Joins("Orders").Where("orders.status = ?", "paid")实际过滤的是 JOIN 后的行，可能把没订单的用户也筛掉——这不是 bug，是 LEFT JOIN 变 INNER JOIN 的自然结果 - 外键字段名不一致（比如数据库是
creator_id，结构体写UserID uint却没配gorm:"foreignKey:CreatorID"），JOIN 条件生成错误，SQL 报错或返回空
Preload 带条件时必须显式 Select 外键字段
Preload("Orders", "status = ?", "paid") 看起来没问题，但若 Order 结构体里没定义 UserID uint 字段，或数据库列名是 user_id 却没加 gorm:"column:user_id"，GORM 就无法把查到的订单绑定到对应用户上，user.Orders 仍是空切片。
根本原因：预加载后的关联映射依赖外键字段值（如 user_id）与主表 ID 对齐。如果该字段没被 SELECT 出来，或类型/名称不匹配，绑定就失败。
- 正确写法：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id", "user_id", "product") }) -
Select()必须包含外键（user_id）和主键（id），否则 GORM 无法构建映射关系 - 别在
Preload条件里用ORDER BY或LIMIT期望控制每个用户的子项数量——它只作用于整个关联查询，不是 per-user
游标分页下 Preload 和 Joins 都要重写逻辑
用 WHERE id > ? 游标分页时，Preload 依然会拿当前页全部用户的 ID 去查订单，逻辑不变；但 Joins 的 SQL 需手动补上游标条件，否则可能漏数据或重复。
容易被忽略的点：游标字段（如 id）必须在 JOIN 后的结果集中可排序，且索引覆盖完整。如果写 Joins("Orders").Order("orders.created_at DESC")，但没把 orders.id 加进 ORDER BY，高并发下同秒创建的订单顺序不可控。
- Preload 游标分页：确保主查询的
WHERE条件能被准确继承到子查询中（GORM 默认支持，但自定义Scopes时可能丢失） - Joins 游标分页：必须在 JOIN 条件后显式加
AND orders.id > ?类条件，且注意 NULL 值处理（LEFT JOIN 下orders.id可能为 NULL） - 无论哪种方式，游标值都应来自上一页最后一条记录的**排序字段组合**（如
id DESC, created_at DESC），单字段游标在数据更新频繁时极易错位
