GORM 不能直接用于 Elasticsearch 分页，因其是关系型数据库 ORM，而 ES 是基于 HTTP/JSON 的搜索引擎，二者协议、查询模型及分页机制（如 from+size、search_after）完全不兼容，强行适配会导致 panic 或空结果。
为什么不能直接用 GORM 做 Elasticsearch 分页
GORM 是关系型数据库 ORM，Elasticsearch 是搜索型 NoSQL 引擎，二者协议、查询模型、分页机制完全不兼容。GORM 的 Limit/Offset 生成的是 SQL，而 ES 需要的是 JSON 查询体 + HTTP 请求；强行把 GORM 查询“套”到 ES 上，会直接 panic 或返回空结果。这不是配置问题，是底层抽象层断裂——db.Where(...).Limit(10).Offset(20) 在 ES 里根本没对应语义。
from + size 分页在 ES 中怎么和 GORM 流程对齐
你在 Gin 路由里收 page 和 page_size，这步可以复用 GORM 项目已有的参数校验逻辑（比如 PageNum 截断为 ≥1、PageSize 限制 ≤100），但计算 from 时必须换算：ES 的 from 是从 0 开始的偏移量，第 1 页 → from=0，第 2 页 → from=page_size，第 N 页 → from=(N-1)*page_size。这和 GORM 的 Offset((page-1)*pageSize) 表达一致，但注意：from + size 总和不能超过 10000（ES 默认 max_result_window）。
常见错误现象：
- 前端传
page=1001、page_size=10→from=10000，ES 返回illegal_argument_exception: Result window is too large - 没加
sort字段（如"sort": [{"id": "asc"}]）→ 分页结果错乱、重复或漏数据（ES 不保证无序查询的稳定性） - 用
match_all+ 大from查全量数据 → 协调节点内存爆掉，请求超时
深度分页必须切到 search_after，别碰 scroll
当业务需要翻到第 5000 页（即 from ≥ 50000），from + size 已不可行。此时必须改用 search_after，它不依赖全局偏移，而是基于上一页最后一条文档的排序值继续拉取。关键点：
-
search_after要求排序字段（如id或timestamp）**全局唯一且非空**，否则可能跳过或重复文档 - 不能随机跳页（比如用户直接输“第 888 页”），只能顺序下一页；前端需隐藏页码输入框，只留“下一页”按钮
- GORM 里没有等价封装，你得手动从上一页响应中提取
hits.hits[-1].sort数组，拼进下一次请求的search_after字段 - 别用
scroll：它依赖搜索上下文快照，不适合在线 API（上下文超时后无法续查），且不反映实时写入，Gin handler 里维护scroll_id也违背无状态原则
GORM 和 ES 分页结果怎么合并返回
典型场景：用户搜“北京”，ES 快速召回 ID 列表，再用这些 ID 查 GORM 关联的完整结构体（如用户头像、权限字段）。这时分页逻辑要拆成两步：
- 第一步：ES 查询，用
from/size或search_after拿到[]string{ "1001", "1002", ... "1010" }（10 个主键） - 第二步：GORM 查库，
db.Where("id IN ?", esIds).Order("FIELD(id, ?)", esIds).Find(&users)—— 注意加ORDER BY FIELD（MySQL）或CASE WHEN（PostgreSQL）保持 ES 返回的顺序，否则分页错位 - 总数不能复用 ES 的
hits.total.value直接当 GORM 总数——ES 总数是匹配文档数，GORM 总数是能查出完整对象的数（比如某些 ID 对应记录已被软删除）；如需精确总数，得走 GORM 的Count，但代价高，通常前端只显示“约 XXX 条”即可
最容易被忽略的一点：ES 返回的 ID 是字符串还是整数？GORM 模型里的 ID 字段类型必须和 ES 存储的 id 类型严格一致（比如 ES 里 "id": "123"，GORM 就不能定义 ID uint），否则 IN 查询失效，返回空切片。
