Limit+Offset分页在订单历史中会丢数据或重复，因新订单插入导致OFFSET跳过的物理行漂移；且深度分页性能差。应改用游标分页，以created_at DESC, id DESC为锚点，配合联合索引，避免COUNT不准和Preload N+1问题。
为什么 Limit + Offset 在订单历史分页中会丢数据
订单表频繁插入新记录（如支付成功、退款、状态变更），OFFSET 跳过的“物理行数”会随写入实时漂移。比如第 50 页请求刚发出，后台又插入 3 条订单，同一 OFFSET 990 LIMIT 20 可能漏掉这 3 条，或让某条订单在第 49 页和第 51 页重复出现。这不是 GORM 的 bug，是 SQL 标准下无序扫描的必然行为。
更严重的是性能：当用户翻到第 1000 页（OFFSET 19980），MySQL 必须真实读取并丢弃前 19980 行——哪怕只用到索引，I/O 和 CPU 开销也陡增。线上常见现象是接口响应从 50ms 拉长到 2s+，DB 连接池打满。
- 必须显式指定
Order("created_at DESC, id DESC")：仅用created_at DESC不够，高并发下单时间可能重复，二级排序id DESC保证顺序唯一 - 排序字段必须有联合索引：
INDEX idx_created_id (created_at, id)，否则ORDER BY会触发 filesort - 别把前端传的
page直接算成OFFSET，尤其在“我的订单”这类强一致性场景下不可靠
游标分页怎么写才不重复不漏单
游标分页本质是“记住上一页最后一条的锚点，往后取”。对订单历史，锚点必须是确定性、单调、有索引的字段组合。推荐用 created_at DESC, id DESC，首次请求不带条件，后续请求用上一页最后一条的两个值构造 WHERE。
示例逻辑：
db.Order("created_at DESC, id DESC").Limit(20).Find(&orders)拿到 orders[len(orders)-1] 后，下次请求带参数 cursor_created_at=2026-08-20T14:22:33Z&cursor_id=123456，后端拼：
db.Where("created_at < ? OR (created_at = ? AND id < ?)",
cursorCreatedAt, cursorCreatedAt, cursorID).
Order("created_at DESC, id DESC").
Limit(20).
Find(&orders)- 前端必须透传
cursor_created_at和cursor_id，不能转成page=51再计算——这是最常被忽略的协议约定 -
created_at字段类型建议用DATETIME(3)或BIGINT时间戳，避免 MySQL 默认秒级精度导致多条同秒时无法区分 - 首次请求不要传 cursor 参数，否则 WHERE 条件为空，查不到数据
- 如果用户手动刷新第 1 页，需清空 cursor，不能复用上一次的 last_id
Count 总数查询为什么总是不准
直接在分页链上连写 Count() 是高频错误：db.Where("user_id = ?", uid).Offset(1000).Limit(20).Count(&total) 返回的 total 永远是 ≤20 的数——GORM 的 Count() 会继承前面的 Limit 和 Offset，根本不是总记录数。
正确做法是隔离会话：
db.Session(&gorm.Session{NewDB: true}).Model(&Order{}).Where("user_id = ?", uid).Count(&total)- 复杂关联（如预加载用户信息、商品 SKU）时，
Count()无法自动处理JOIN，必须手写子查询：db.Raw("SELECT COUNT(*) FROM orders WHERE user_id = ?", uid).Scan(&total) - 如果业务允许弱一致性（比如分页控件只显示“还有更多”，不显示精确页码），可省掉
COUNT，改查size + 1条，判断是否还有下一页 - 别在同一个事务里先
Count再Find：两次查询之间若有新订单插入，总数和当前页数据就对不上
Preload 关联数据时怎么避免 N+1 和超量加载
在订单分页中常需加载用户、商品、地址等关联信息。但直接 Preload("User").Preload("Items") 会导致 GORM 先查出 20 个订单 ID，再发 20 条 SELECT * FROM users WHERE id IN (…)——看似合理，实则放大了数据库压力，且无法控制每个订单只取最新 3 个商品。
更稳的两步法：
- 第一步：用游标分页查出 20 个
order.id列表（不加Preload） - 第二步：用
IN批量查关联数据：db.Where("order_id IN ?", orderIDs).Find(&items)，再在 Go 层按order_id分组 - 如果要限制每个订单的商品数（如只取前 3 个），不能靠
Preload实现，得用窗口函数或子查询，例如：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC) rn FROM items) t WHERE t.rn
游标分页的锚点字段必须稳定、单调、有索引，而关联表数据变动不影响主表游标逻辑——这点比传统分页干净得多。真正难的不是写 SQL，是让前端理解并正确透传 cursor。
