from/size分页在ES中因协调节点合并排序导致超过10000报错；scroll已弃用且不适合在线翻页；search_after才是正解，需严格有序字段、手动传递sort值、禁用跳页，并确保排序字段启用doc_values及时区一致。
from/size分页在PHP中直接失效的根源
PHP里写 from 和 size 参数看似和SQL一样，但Elasticsearch会在协调节点上合并所有分片的 from + size 条结果再排序——当这个值超过默认的 10000，ES直接返回 Result window is too large 错误。这不是PHP代码写错了，是ES主动拒绝执行。你无法靠调大 index.max_result_window 来绕过，因为内存开销会指数级增长，集群可能被拖垮。
scroll分页只适合后台导出，别用在用户请求里
PHP调用 search() 传 scroll="2m"，再反复用 scroll() 拿数据，确实能翻到第10万页。但它本质是拍快照，后续写入的数据不会出现在滚动结果中，且每个scroll上下文长期占用JVM堆内存。官方在ES 9.x中已明确标注scroll为“deprecated for user-facing pagination”。你在PHP里看到的 SearchResponseIterator 自动调用 clearScroll()，只是帮你收尾，不改变它不适合在线翻页的事实。
search_after才是PHP翻页的正解
它要求你必须有全局唯一、严格有序的字段（比如 timestamp + _id），每次请求带上上次最后一条的排序值。PHP实现的关键点：
- 首次查询不能带
from，必须用sort明确指定至少两个字段，例如：["updated_at" => "desc", "_id" => "desc"] - 响应里的
hits['hits']最后一项的sort值（数组），要原样塞进下一页的search_after参数里 - PHP客户端不自动拼接
search_after，你得手动构造：$params['body']['search_after'] = $lastHit['sort']; - 不能跳页，只能逐页往后，所以前端“跳转到第N页”按钮必须禁用或转为时间范围筛选
示例片段：
立即学习“PHP免费学习笔记（深入）”；
$params = [
'index' => 'products',
'size' => 20,
'body' => [
'query' => ['match' => ['title' => '手机']],
'sort' => [
'updated_at' => ['order' => 'desc'],
'_id' => ['order' => 'desc']
]
]
];
$response = $client->search($params);
$lastHit = end($response['hits']['hits']);
$nextSearchAfter = $lastHit['sort'] ?? null;
PHP翻页逻辑必须和服务端排序强绑定
很多人把 search_after 当成换汤不换药的 from 替代品，结果翻着翻着就漏数据或重复。根本原因是：PHP里没校验排序字段是否建了索引、是否启用 doc_values、有没有被设置为 keyword 类型。比如对 text 字段做 sort，ES会默默失败或返回空结果。务必确认映射里类似这样的配置已生效：
"updated_at": {
"type": "date",
"doc_values": true
}
另外，search_after 对时区敏感，PHP传入的时间戳必须和ES里存储的时区一致，否则跨页边界会错位。最稳妥的方式是统一用UTC时间存、查，PHP里用 gmdate() 格式化。
