GORM事务内分页不安全，OFFSET/LIMIT和FindInBatches均可能跳过或重复记录；唯一可靠方案是基于游标的分页，需确定性排序与联合索引支持。
直接说结论：GORM 的分页查询本身不支持事务内安全分页，尤其在高频变动数据场景下，OFFSET/LIMIT 和 FindInBatches 都可能跳过或重复记录——这不是 bug，是数据库快照隔离级别的必然结果。
为什么事务里用 OFFSET 分页会丢数据？
当你在一个长事务中反复执行 db.Offset(n).Limit(100).Find(&items)，数据库（如 MySQL RR 隔离级）会基于事务开启时的快照读取数据。但如果你在事务中又插入/删除了记录，后续分页的 OFFSET 仍按原始快照计算，导致实际跳过的行数与预期不符。
- 现象：第 1 页查到 ID 1–100，第 2 页本该查 101–200，却查到 ID 102–201（中间 ID 101 被其他事务删了），或者 ID 100–199（新插入的 ID 101 没被看到）
- 根本原因：
OFFSET是逻辑偏移，不是物理位置；事务快照冻结了“可见行集合”，但不冻结“行顺序” - 别指望
SELECT ... FOR UPDATE能解决——它只锁住当前查到的行，不锁住未来可能被 offset 跳过的行
FindInBatches 在事务中是否更可靠？
不。虽然 FindInBatches 底层用主键范围（如 WHERE id > ? ORDER BY id LIMIT ?）避免了 OFFSET 性能退化，但它默认不感知事务上下文，且要求模型必须有单调递增、无空洞的主键（如自增 id）。一旦表存在软删除、并发插入或复合主键，就容易漏数据。
- 典型错误写法：
tx.FindInBatches(&users, 100, func(tx *gorm.DB, batch int) error { ... })—— 这里的tx是传入的事务实例，但批次间没有状态同步，第二次 batch 仍从头扫描 - 正确姿势：必须手动维护游标，比如上一批最后的
id值，下一批用WHERE id > lastID ORDER BY id LIMIT 100 - 注意：MySQL 的
AUTO_INCREMENT并非严格连续，主键空洞会导致跳过整段数据
高频变动数据分页的可行方案
放弃“页码+页大小”思维，改用基于游标的分页（cursor-based pagination），这是唯一能在事务和高并发下保持一致性的做法。
- 核心逻辑：每次返回结果时附带一个
cursor（通常是最后一条记录的id或updated_at+id组合），前端下次请求带上它，后端用WHERE (updated_at, id) > (?, ?) ORDER BY updated_at, id LIMIT 100 - GORM 实现示例：
db.Where("updated_at > ? OR (updated_at = ? AND id > ?)", cursorTime, cursorTime, cursorID).Order("updated_at, id").Limit(100).Find(&items) - 关键约束：必须有确定性排序字段（不能只用
ORDER BY RAND()）、索引要覆盖(updated_at, id) - 事务内使用：只要游标字段在事务开始前已确定（比如从第一次查询拿到），后续批次可安全复用该快照值
容易被忽略的底层细节
很多人以为加个 db.Session(&gorm.Session{PrepareStmt: true}) 就能优化分页性能，其实它只缓存预编译语句，对 OFFSET 的 O(n) 扫描毫无帮助。真正影响高频分页稳定性的，是索引设计、事务生命周期、以及是否接受“最终一致性”——比如后台导出任务可以容忍少量重复，但支付流水核对绝对不能。
