count总数不准源于gorm count不继承joins/preload等上下文，仅硬扫主表；preload分页需先order保证id稳定；游标分页须用join后唯一排序字段组合。
多表关联分页时 Count() 总数不准的根源
直接在带 Joins 或 Preload 的链式调用后接 Count(&total)，得到的永远是错误总数。GORM 的 Count 不继承 Joins、Preload、Group 等上下文，它只按模型表硬扫，条件也常被忽略。
常见错误现象：db.Joins("JOIN orders ON users.id = orders.user_id").Where("orders.status = ?", "paid").Count(&total) 返回的是所有用户数，而非“有已支付订单的用户数”。
- 简单场景：用
db.Session(&gorm.Session{NewDB: true}).Model(&User{}).Joins("JOIN orders ...").Where(...).Count(&total)隔离会话，但仅限无Preload的纯Joins - 复杂场景（含
Preload、嵌套Joins、GROUP BY）：必须手写子查询，例如db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = ?) t", "paid").Scan(&total) - 别在事务里反复查
Count+Find，两次查询间若数据变更，总数和当前页记录可能不一致
Preload 分页的正确姿势
Preload 本身不参与分页逻辑，但若直接对主表分页再 Preload 关联数据，会触发 N+1 或结果错乱——因为 Preload 是在分页后的主键集合上查关联表，而分页前没做去重或排序约束，容易漏关联数据。
- 先确保主查询有确定性排序：
.Order("users.id ASC")，避免因无序导致Preload拿到的 ID 列表不稳定 - 若需按关联字段筛选（如“查最近下单的用户”），不能靠
Preload后过滤，得把条件下推到Joins中，再分页 - 慎用
Preload+Limit组合：GORM v2 默认对每个Preload单独发 SQL，分页 Limit 只作用于主表，关联数据仍全量加载
游标分页在关联场景下的落地难点
多表关联时，游标字段不能只取主表 id —— 因为 JOIN 后结果集行数膨胀，同个主表 id 可能对应多条记录，导致游标失效或重复。
- 游标必须基于最终排序字段组合，且该组合在
JOIN后仍唯一：例如ORDER BY orders.created_at DESC, orders.id DESC，游标传last_created_at和last_order_id - WHERE 条件要严格匹配排序字段的单调性：若用
created_at DESC，后续查询写WHERE orders.created_at - 前端必须透传多个游标值（不止一个
last_id），后端不做拼接或转换，否则精度丢失
索引与性能断崖的隐性依赖
无论用 Offset 还是游标，只要 ORDER BY 字段没覆盖索引，分页性能就会断崖下跌——尤其在关联查询中，数据库可能放弃使用主表索引，转而走全表扫描 + filesort。
- 检查执行计划：
EXPLAIN SELECT ... JOIN ... ORDER BY orders.created_at DESC, orders.id DESC LIMIT 20，确认key列是否命中索引 - 复合索引必须包含所有
WHERE条件字段 +ORDER BY字段，顺序要匹配，例如(status, created_at, id)支持WHERE status = ? ORDER BY created_at DESC, id DESC - 避免在
ORDER BY中混用 ASC/DESC（MySQL 8.0 前不支持混合方向索引），统一用DESC或都用ASC
最易被忽略的一点：游标分页看似绕开了 OFFSET，但若排序字段缺乏索引或 WHERE 条件无法利用索引，它一样会慢——游标不是银弹，只是把性能瓶颈从“跳过N行”转移到“高效定位起点”。
