`search_after` 确实不支持随机访问（即直接跳到任意一页），因此在前端需要随机跳转到某一页的场景中，使用 `search_after` 是不合适的。这种情况下，更适合使用 `from` 和 `size` 来实现分页。
为什么 `search_after` 不支持随机访问
`search_after` 的工作原理是基于排序字段的值，从上一页的最后一个结果之后继续查找下一页的结果。它依赖于结果的顺序性，因此只能顺序分页。如果需要跳转到任意一页，`search_after` 无法直接实现，因为它无法像 `from` 和 `size` 那样通过偏移量直接定位到目标页。
前端分页场景的适用性
- 随机访问分页（适合 `from` 和 `size`）
如果前端允许用户直接跳转到任意一页（例如用户可以直接输入页码，或者点击"第 100 页"这样的按钮），那么应该使用 `from` 和 `size`。这种方式可以方便地通过偏移量（`from`）直接定位到目标页。
-
优点：
-
支持随机访问，用户可以自由跳转到任意一页。
-
实现简单，前端和后端的逻辑都比较直观。
-
缺点：
-
当分页深度较大时（例如 `from` 值很大），性能会显著下降，因为 Elasticsearch 需要加载和丢弃大量中间结果。
- 顺序分页（适合 `search_after`）
如果前端的分页逻辑是顺序的（例如用户只能通过"下一页"或"上一页"按钮逐步浏览），那么可以使用 `search_after`。这种方式在深度分页时性能更好，因为它不需要加载和丢弃大量中间结果。
-
优点：
-
性能高效，适合深度分页。
-
资源占用低，对集群的压力小。
-
缺点：
-
不支持随机访问，用户不能直接跳转到任意一页。
-
实现相对复杂，需要正确处理排序字段和排序值的传递。
前端分页的实现建议
如果你需要在前端实现分页功能，可以根据具体需求选择合适的分页方式：
-
如果需要支持随机访问（用户可以跳转到任意一页）：
-
使用 `from` 和 `size`。
-
在后端查询时，根据前端传入的页码计算 `from` 的值（`from = (page - 1) * size`）。
-
示例：
```json
GET /my_index/_search
{
"from": 990, // 假设每页 10 条，跳转到第 100 页
"size": 10,
"query": {
"match_all": {}
}
}
```
-
如果只需要顺序分页（用户只能通过"下一页"或"上一页"浏览）：
-
使用 `search_after`。
-
在后端查询时，根据上一页的最后一个结果的排序值，设置 `search_after` 参数。
-
示例：
```json
GET /my_index/_search
{
"size": 10,
"query": {
"match_all": {}
},
"sort": [
{ "_doc": "asc" }
],
"search_after": "12345" // 假设上一页的最后一个结果的 _doc 值为 12345
}
```
总结
-
如果前端需要支持随机访问分页（用户可以跳转到任意一页），建议使用 `from` 和 `size`。
-
如果前端只需要顺序分页（用户只能通过"下一页"或"上一页"浏览），并且需要处理大量数据，建议使用 `search_after`。
根据你的描述，如果前端允许用户随意点击某一页，那么确实不适合使用 `search_after`，而应该使用 `from` 和 `size` 来实现分页功能。