直接修改index.max_result_window最危险，因不解决内存溢出而只延迟错误；Laravel深度分页爆内存根源在于ES分布式分页机制——协调节点需拉取并全局排序海量中间数据，PHP进程随之耗尽内存；Search After是实时分页唯一靠谱方案，以排序值为书签跳过计算，性能恒定，但需全局唯一排序字段且不支持跳页；Scroll API适合后台导出，基于快照避免实时压力，但不实时且须手动清理；PIT+Search After可锁定翻页期间数据视图一致性；所有方案均要求sort字段启用doc_values以避免OOM。
直接改 index.max_result_window 是最危险的“解法”——它不解决内存溢出，只让错误来得更晚、更猛。
为什么 Laravel + ES 深度分页会爆内存？
不是 Laravel 的锅，是 Elasticsearch 的分页机制本身在分布式环境下天然吃内存：
- 协调节点必须从每个分片拉取
from + size条数据（比如from=99990, size=10→ 每个分片返回 100000 条） - 所有分片结果汇总后，协调节点要在内存里做全局排序，再丢弃 99990 条
- Laravel 如果用
Http::post()或elasticsearch-php客户端直接发from/size请求，等于把这堆中间数据全读进 PHP 进程内存 - PHP 内存限制（如
memory_limit=512M）很快被撑爆，报Fatal error: Allowed memory size exhausted
Search After 是 Laravel 实时分页唯一靠谱的选择
它用上一页最后一条文档的排序值当“书签”，跳过所有中间计算，性能几乎恒定。
- 必须有确定的、全局唯一的排序字段（推荐
sort: ["@timestamp": "desc", "_id": "asc"]） - 首次查询不带
search_after，但必须带sort和size，响应体里取hits.hits[-1].sort值 - 下一页请求传
"search_after": [1723548600000, "abc123"]（注意数组顺序要和 sort 字段严格一致） - Laravel 示例（用官方 elasticsearch-php 客户端）：
$params = [ 'index' => 'logs', 'body' => [ 'sort' => [ '@timestamp' => ['order' => 'desc'], '_id' => ['order' => 'asc'] ], 'size' => 50, 'search_after' => $lastSortValues ?? null, 'query' => [...] ] ]; - 不能跳页（比如从第 1 页直接到第 100 页），但无限滚动场景完全够用
Scroll API 只适合 Laravel 后台导出任务
它生成快照，绕开实时排序压力，但代价是资源占用高、不实时、必须手动清理。
- 首次请求加
"scroll": "2m"，拿到_scroll_id - 后续请求用
POST /_search/scroll+_scroll_id拉下一批，直到hits.hits为空 - 导出完成必须调
DELETE /_search/scroll清理上下文，否则长期占用 JVM 堆内存 - PHP 脚本里记得设超时：
set_time_limit(0)，并用ob_flush()+flush()边拉边写 CSV 文件，避免全量缓存 - 如果数据量极大（千万级），优先用
sliced scroll并行拉取，但需确保索引已按时间等维度合理分片
PIT + Search After：当你的 Laravel 列表页要求“翻页过程中结果不变”
比如运营后台查订单，用户翻页时新订单不断写入，但希望整个翻页过程看到的是同一份数据视图。
- 第一步：先创建 PIT（Point in Time）
POST /orders/_pit?keep_alive=1m // 返回 {"id": "12345..."} - 第二步：所有
search_after查询都带上"pit": {"id": "12345...", "keep_alive": "1m"} - PIT 有生命周期，每次查询后要刷新
keep_alive，或在最后一次请求后显式删除：DELETE /_pit?id=12345... - 比纯
search_after多一次网络往返，但能锁住数据一致性；Laravel 中建议封装成服务类统一管理 PIT 生命周期
最容易被忽略的是：无论用哪种方案，Elasticsearch 的 sort 字段必须开启 doc_values: true（text 类型字段默认关闭），否则会强制加载 fielddata 到堆内存，直接触发 OOM。检查命令：GET /your_index/_mapping?filter_path=**.doc_values。
