订单分页必须用游标分页而非Limit+Offset，因高频写入、时间重复、跳页导致Offset漏单/重复/性能陡降；应以id为锚点升序或降序查询，禁用page换算，模糊分页用Limit(n+1)判断下一页，精确总数需手写子查询或缓存。
订单历史数据分页不能只靠 Limit + Offset 硬扛，尤其当表超 50 万行、日增千条以上时，第 100 页开始明显变慢，且翻页时容易漏单或重复——这不是 GORM 的 bug，是 SQL 分页模型本身的限制。
为什么订单表用 Offset 分页特别容易出事
订单数据有高频写入（支付成功、退款、状态变更）、时间字段重复率高（同一秒多笔下单）、用户常跳页（直接点“最后一页”），这三者叠加会让 OFFSET 行为失控：
- 没加
Order("id ASC")或Order("created_at DESC, id DESC")时，MySQL 可能对同秒创建的订单返回不同顺序，导致第 3 页刷两次内容不一致 -
Offset(9999)查第 1000 页（每页 10 条）时，MySQL 必须扫描并丢弃前 9999 行，哪怕id有索引，I/O 和 CPU 也陡增 - 用户查第 50 页时，后台正批量更新 1000 条订单状态，
Count和Find之间数据已变，总数和当前页记录对不上 - 用
Preload("Items")分页，GORM 会先取 10 个订单 ID，再发一条SELECT * FROM items WHERE order_id IN (?,?,?)——但如果某订单有 200 个商品，这一条 SQL 就拖慢整页响应
手写 Limit + Offset 的安全写法（中小订单量适用）
若订单表当前 Limit/Offset，但必须卡死以下四点：
- 参数校验：用结构体绑定，
PageNum小于 1 则设为 1；PageSize超过 50 就截断（订单列表一般不用显示超 50 条/页） -
Order必须显式写：优先Order("id DESC")（主键递增稳定），次选Order("created_at DESC, id DESC")（防时间重复） - 总数查询隔离：不能复用同一个
*gorm.DB实例，得用db.Session(&gorm.Session{NewDB: true}).Model(&Order{}).Where(...).Count(&total) - 避免
Preload：改用两步查——先Find(&orders)拿 ID 列表，再Where("order_id IN ?", orderIDs).Find(&items)批量加载，可控且可加LIMIT
订单量 > 50 万后必须切游标分页
游标分页不是“可选优化”，而是订单类业务的分页底线。它不依赖页码，只依赖上一页最后一条的锚点值：
- 首次请求：用
Order("id DESC").Limit(20).Find(&orders)，取orders[0].ID作为首屏 last_id - 后续请求：前端传
last_id=123456，后端查Where("id < ?", last_id).Order("id DESC").Limit(20)（注意是<，不是>，因按 ID 降序） - 别混用时间字段：如果用
created_at做游标，得处理时区、精度（建议用BIGINT存毫秒时间戳），且必须加id二级排序兜底，否则同毫秒订单顺序不可控 - 前端必须透传
last_id，不能在后端把page=5换算成last_id——那又绕回 Offset 的坑里
Count 总数在订单场景下要不要查
订单历史页的“共 N 条”对用户体验价值有限，但开发常默认加上。其实有更轻量的选择：
- 如果允许模糊页码（如“上一页 / 下一页”按钮，不显示总页数），直接查
Limit(21)，若结果长度 = 21，就说明还有下一页，返回has_next: true，省掉一次COUNT(*) - 如果必须返回精确总数，且订单表有复杂条件（如
WHERE status IN (1,2,3) AND user_id = ?），别信db.Model().Count()—— 它不继承Joins或嵌套Where，应手写子查询：db.Raw("SELECT COUNT(*) FROM (SELECT 1 FROM orders WHERE ...) AS t").Scan(&total) - 高并发查总数时，可考虑缓存：比如每小时跑一次
SELECT COUNT(*) FROM orders WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)，存 Redis，误差可接受
最易被忽略的一点：游标分页的 last_id 必须来自数据库真实返回字段，不能前端自己拼、后端再解析——任何中间转换（比如转字符串再转 int）都可能引入空格、溢出或类型错位，直接导致查不到数据或越界 panic。
