内连接分页可用Limit+Offset，因结果集稠密；左外连接分页须用Select+Scan避免NULL导致丢记录；Preload分页低效且无效；高偏移应改用游标分页，总数统计需与分页查询完全一致。
内连接分页直接用 Limit + Offset 就行
内连接天然只返回匹配成功的记录，结果集稠密、无 NULL 行，所以 Limit 和 Offset 能准确截取第 N 页数据。比如查订单及其用户姓名，用 Joins("INNER JOIN users ON orders.user_id = users.id") 拼接后，直接链式调用 Offset 和 Limit 即可。
常见错误是把 Preload("User") 放在分页前：先 Limit(10).Offset(20) 查出 10 条订单，再为每条发一次关联查询——这实际查了主表 10 条，但关联数据全量加载，内存和网络开销翻倍。
- 必须显式写
Order("orders.id DESC")，否则分页结果不稳定 - 字段多时建议用小结构体接收（如
type OrderWithUserName struct { ID uint; Name string; UserName string }），避免大结构体拖慢序列化 - WHERE 条件里别过滤关联表字段（如
WHERE users.status = 'active'），否则左外连接会退化成内连接；该条件得挪进ON子句
左外连接分页必须用 Select + Scan
Find 在左外连接场景下会失效：遇到 NULL 关联时，GORM 把整个关联结构体置为零值（如 User{}），甚至可能丢掉主表记录，看起来像内连接。真正生效的做法是绕过 Find 的自动映射，改用 Select 显式指定字段，再 Scan 到自定义结构体。
示例：db.Joins("LEFT JOIN users ON orders.user_id = users.id").Select("orders.*, users.name as user_name").Scan(&results)
立即学习“go语言免费学习笔记（深入）”；
- 结构体字段名必须和
Select中的别名严格一致（user_name→UserName string） -
Count查询不能复用同一*gorm.DB实例，否则会继承前面的Limit/Offset，得用db.Session(&gorm.Session{NewDB: true})隔离 - MySQL 的
SQL_CALC_FOUND_ROWS已废弃，总数统计建议手写子查询或额外Count调用
Preload 分页无效且低效
Preload 是 N+1 查询模式：先查主表（带分页），再对每条主记录发一次关联查询。一页 20 条订单，就额外发起 20 次用户查询——即使 GORM 做了 IN 批量优化，也受限于连接池压力和预加载策略。
-
Preload("Orders", db.Limit(3))在 GORM v2.6.0 前不生效，文档旧示例别信 - 无法限制“每个用户只取最新 3 个订单”这类需求，
Preload只能全量加载或按全局 limit 截断 - 一对多分页推荐方案：主表分页查 ID 列表 → 子查询查关联数据 → 应用层合并
游标分页才是高偏移场景的解法
当 Offset 超过 10 万，或业务要求“无限滚动”，传统分页必须放弃。MySQL/PostgreSQL 对大偏移量是真实扫描并丢弃前 N 行，不是跳指针。游标分页依赖上一页最后一条记录的排序字段值（如 id 或 created_at），每次只扫增量数据。
- 排序字段必须有索引，且全局唯一或严格单调——
id最稳妥，created_at高并发下可能重复，需加id作二级排序 - GORM 写法：
db.Where("id > ?", lastID).Order("id ASC").Limit(20).Find(&users) - 别在游标分页里混用
Preload，关联数据应分两步：先查主表 ID 列表，再用WHERE id IN (?)批量加载
关联分页最易被忽略的点是：总数统计逻辑必须和分页查询完全一致——连 JOIN 条件、WHERE 子句、甚至数据库方言都不能差一点，否则前端页码会错乱。这不是 GORM 的锅，是 SQL 本身的要求。
