preload 不能与分页混用，因分页作用于主表，preload 仅填充关联字段；条件 preload 需显式 select 外键字段，否则静默失败；嵌套预加载限一级且需 gorm v2.2.5+；关联分页需手动处理去重与聚合。
Preload 不能和分页直接混用
在 Find() 前加 Preload("Orders") 再接 Limit(10).Offset(20)，GORM 会先查出 10 个用户，再发一条 SELECT * FROM orders WHERE user_id IN (1,2,...,10) —— 这看似省了 N+1，但实际加载的订单数远超 10 条，且无法控制“每个用户只取最新 2 个订单”。更关键的是：Count() 统计的是用户总数，不是订单总数，分页语义错位。
- 分页对象是主表（如
User），Preload只负责填充其关联字段，不改变分页粒度 - 想对关联数据做分页（如“每个用户展示最近 3 笔订单”），
Preload本身做不到，必须拆解或换方案 - 若强行在
Preload里加Limit（如Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Limit(3) })），GORM v2.2.5+ 才支持，且仅限一级关联；嵌套层级（如Preload("Orders.Items")）仍会失效
条件 Preload 必须显式 Select 外键字段
Preload("Orders", db.Where("status = ?", "paid")) 看似合理，但若 Orders 表没被 Select 出 user_id 字段，GORM 就无法把查到的订单绑定回对应用户，结果是 user.Orders 仍是空切片 —— 没报错，只是静默失败。
- 正确写法：在条件预加载中强制指定外键或主键字段，例如
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id", "user_id", "amount") }) - 如果只关心是否存在（比如加个
has_paid_order标志），用.Select("user_id").Limit(1)比全量字段快得多 - 调试时打开
Debug()，确认生成的第二条 SQL 是否含WHERE user_id IN (?)和你指定的字段
分页 + 关联数据去重和聚合得手动做
当主表查询用了 Joins 或聚合函数（如 GROUP BY），再跟 Preload，很容易出现 user.Orders 切片长度异常 —— 同一个 User.ID 对应多条 Order，Preload 不合并，直接平铺塞进切片，导致长度翻倍甚至更多。
- 先检查主查询是否无意放大了行数：比如
Joins("LEFT JOIN orders")却没加Distinct，或Where条件漏写了关联表过滤 - 若主表已去重（如用
SELECT DISTINCT ON (users.id) ...），可查完后用map[uint]User按 ID 聚合，再遍历订单列表往对应用户里 append - 小数据量（Joins + 手动字段映射，或物化视图预计算
真正需要“关联分页”的场景该用 Joins + 子查询
比如“查第 2 页用户，每人只显示最新 2 笔已完成订单”，Preload 无解。此时应放弃嵌套结构体，转为扁平字段 + Joins，靠子查询或窗口函数控制关联数据条数。
- PostgreSQL 示例：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)筛出每用户的前 2 条 - MySQL 8.0+ 同理；旧版 MySQL 可用
(SELECT ... FROM orders o2 WHERE o2.user_id = users.id ORDER BY created_at DESC LIMIT 2)作为字段，但性能差 - GORM 中写法：先
Joins("LEFT JOIN (...) AS latest_orders ON ...")，再Select("users.*, latest_orders.product, ...")，最后Scan(&results)到自定义 struct
Preload 是为“主表分页 + 全量关联数据”设计的，不是通用联表分页工具。一旦需求越过“每个主记录配一堆子记录”的边界，就得跳出 Preload 思维，直面 SQL 表达力。
