gorm与elasticsearch不能共用同一套分页逻辑，因二者底层机制不同：gorm依赖sql的limit/offset物理偏移，需稳定排序防跳行；es使用from/size逻辑偏移，受分片、排序稳定性及快照影响，且默认max_result_window=10000限制深度分页。
为什么GORM和Elasticsearch不能共用同一套分页逻辑
因为二者底层机制完全不同：GORM 分页靠 LIMIT 和 OFFSET 拼 SQL，而 Elasticsearch 的 from + size 是协调节点合并各分片前 N+M 条再截取——这导致同样“第 100 页、每页 20 条”，GORM 查的是数据库里跳过 1980 条后的 20 条，ES 却要让每个分片都返回 2000 条以上再全局排序。更关键的是，ES 默认 max_result_window=10000，from=10000 就直接报错 result window is too large，而 GORM 没这限制（但会慢）。
- GORM 的
Offset是物理偏移，依赖主键或时间字段稳定排序才不会漏/重 - ES 的
from是逻辑偏移，受分片数、排序稳定性、快照一致性共同影响 - 两者总数统计方式也不同：GORM 要额外
Count()，ES 可从hits.total.value直接读，但这个值在track_total_hits=false时不准
什么时候该用 GORM 分页，什么时候该切到 ES 分页
看查询意图和数据特征：
- 查“用户列表+按创建时间倒序+支持关键词模糊匹配” → 用 GORM：数据量可控（
- 查“商品全文搜索+按销量+价格区间+多标签过滤+实时排序” → 用 ES：字段非结构化、排序依赖相关性（
_score）、数据量大（千万级）、接受最终一致性 - 混合场景（如先搜 ES 得 ID 列表，再用 GORM 查详情）→ 分页必须拆开：ES 负责
search_after或scroll做结果集导航，GORM 负责单条或小批量加载，不能把 ES 的from直接喂给 GORM 的Offset
如何安全地桥接 GORM 与 ES 的分页参数
常见错误是把前端传的 page=5、page_size=20 同时塞给两边。实际要分层转换：
- 对 GORM 层：校验
page≥ 1，page_size∈ [1, 100]，算offset = (page-1)*page_size，且必须加Order("id DESC")（哪怕业务不关心 ID，也要保证顺序可复现） - 对 ES 层：若用
from + size，只允许from ≤ 9980（预留 20 条），否则强制降级为search_after；首次请求不带search_after，后续请求必须携带上一页最后一条的sort值数组（如["2026-08-20T10:30:00", 12345]） - 总数同步：GORM 查
Count()得精确值；ES 查hits.total.value仅作参考，若 > 10000 则显示“10000+”而非具体数字
容易被忽略的深坑：排序字段唯一性与数据新鲜度
这是跨系统分页最常崩的点。GORM 中 Order("created_at DESC") 在毫秒级并发写入时可能产生相同时间戳，导致分页跳行；ES 中 "sort": [{"created_at": "desc"}] 若没加 "_id" 保底，多个文档同秒创建就会打乱 from + size 的位置计算。
- GORM 必须补二级排序：例如
Order("created_at DESC, id DESC")，确保组合值全局唯一 - ES 必须显式声明复合排序：
"sort": [{"created_at": "desc"}, {"_id": "desc"}]，否则search_after无法准确定位下一页起始点 - ES 的
scroll和PIT虽能保一致性，但它们冻结了数据快照——用户刚下单，GORM 查到新记录，ES scroll 还在旧快照里，这种割裂必须由业务层兜底（比如 scroll 仅用于导出，不用于在线列表）
