Preload + Limit/Offset 分页更慢，因GORM先分页再IN查询关联表，导致冗余数据加载、内存归并膨胀及网络传输激增；正确解法是游标分页配合显式Select外键与条件Limit。
Preload + Limit/Offset 分页为什么更慢
在分页查询里加 Preload，表面看是为避免 N+1，实际常导致性能比不加还差。根本原因在于 GORM 的预加载机制和分页逻辑天然冲突：它先执行 Limit/Offset 查出 10 条用户，再用这 10 条的 ID 去查关联表（比如订单），但这个 IN 查询本身不带分页——结果可能一次拉回几百个订单，而你只打算展示每个用户最近 1 个。
- 数据库层：
WHERE user_id IN (1,2,...,10)没有限制订单数量，全量扫描匹配行 - 内存层：GORM 在内存里把订单按 user_id 归并到对应用户上，若某用户有 50 个订单，就生成 50 份冗余用户上下文
- 网络层：传输体积暴涨，尤其字段多时（如
Orders有 15 个字段，10 用户 × 平均 20 订单 = 3000 字段实例）
Preload 条件过滤必须显式 Select 外键
Preload("Orders", db.Where("status = ?", "paid")) 看起来合理，但极大概率返回空切片——GORM 关联映射失败，因为没拿到外键字段 user_id，无法把查到的订单绑定到对应用户上。
- 正确写法：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "paid").Select("id", "user_id", "amount") }) -
Select至少包含外键（user_id）或主键（id），否则Orders字段保持 nil - 如果只要判断“是否有已支付订单”，用
.Select("id").Limit(1)，比全字段快 3~5 倍
游标分页才是预加载场景的解药
当你要分页展示“用户+其最近 3 笔订单”时，Limit/Offset 加 Preload 是死路。游标分页绕过物理偏移，靠排序字段值推进，让预加载真正可控。
- 首请求：
db.Order("users.id ASC").Limit(11).Find(&users)（多查 1 条判断下一页） - 下一页：
db.Where("users.id > ?", lastUser.ID).Order("users.id ASC").Limit(10).Find(&users) - 预加载同步限制：
db.Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Order("created_at DESC").Limit(3) }) - 关键：游标字段（如
id）必须有索引，且不能用created_at单独做游标（高并发下精度不足，需搭配id）
Count 总数查询容易被忽略的陷阱
分页常要总数，但 db.Model(&User{}).Count(&total) 和主查询完全隔离，不会继承 Preload、Joins 或复杂 Where 条件，结果常不准。
- 简单过滤可用：
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Where("status = ?", "active").Count(&total) - 含
Joins或子查询时，必须手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = ?) AS t", "paid").Scan(&total) - 如果前端不强求“共 XX 页”，直接去掉
Count——省一次全表扫描，QPS 可提升 2 倍以上
Select("user_id")），数据就挂了。不是语法报错，而是静默返回空关联，线上难排查。 
