laravel深度分页崩因es主动拒绝，from+size超10000触发限制；应改用search_after实现高效分页，或导出时用scroll api，配合_source过滤、filter缓存及aggs聚合优化性能。
为什么 Laravel 直接用 from + size 查 10w 条会崩
不是 Laravel 的问题，是 Elasticsearch 主动拒绝。当你在 Laravel 中调用类似 search()->from(99900)->take(100) 这种深度分页时，ES 协调节点会要求每个分片都排序并返回前 100000 条候选结果，再全局合并——这会吃光内存、拖慢整个集群。错误信息明确写着："reason":"Result window is too large, from + size must be less than or equal to: [10000]"。它不让你做，是因为真做了，可能让其他查询全卡住。
用 search_after 替代 from 实现高效分页
search_after 不依赖偏移量，而是靠上一页最后一条文档的排序值继续往下翻，跳过全局排序开销。它要求你必须指定稳定、唯一、可比较的 sort 字段（比如 created_at + _id）。
- 在 Laravel 中封装时，不要拼
from，改用原始 DSL 注入search_after数组，例如：["2024-01-01T00:00:00Z", "abc123"] - 第一次请求必须带
sort，且字段不能是text类型（要用keyword或date），否则排序不稳定 - 注意：
search_after不能跳页（比如从第 1 页直接到第 100 页），只适合“下一页”场景；如果业务需要随机跳转，得换方案
Laravel 导出全量数据时别用 chunk()，改用 scroll API
Laravel 的 chunk() 底层仍是 from/size，导出 50 万条时必然触发 10000 限制。ES 原生的 scroll 才是为此设计的：它在首次查询时生成一个快照游标（scroll_id），后续每次用该 ID 拉取下一批，不重新计算排序，也不受 max_result_window 影响。
- PHP 客户端调用时，首次请求加参数
?scroll=2m，响应体里会带_scroll_id - 后续请求用
/_search/scrollendpoint，body 只传{"scroll_id": "...", "scroll": "2m"} - 滚动超时时间（如
2m）要大于单次处理耗时，否则游标失效；导完记得调/_search/scroll?scroll_id=...清理 - 别在用户实时接口里用
scroll——它长期占用服务端资源，只适合后台任务
真正省资源的做法：先缩小结果集，再查详情
很多场景根本不需要拉全字段。比如报表导出只要 ID 和状态，那就用 _source_includes 显式指定字段，避免传输和序列化大文档；更进一步，聚合统计类需求直接用 aggs，让 ES 在服务端算好总数、分组数，Laravel 只收几 KB 结果。
- 在 Scout 或原生客户端中，通过
['_source' => ['id', 'status']]控制返回字段 - 用
filter替代query做精确匹配（如term、range），能复用查询缓存，减少打分开销 - 如果只是要总数，别
size: 0然后遍历 hits，直接看响应里的hits.total.value
深度分页不是“能不能查出来”的问题，而是“要不要这么查”的权衡。ES 的限制背后是集群稳定性，绕过它容易，但忽略它代价更高——尤其当你的索引每天新增几十万文档时，那个被忽略的 search_after 排序字段是否真的唯一、是否被正确映射，往往比代码多写两行更关键。
