必须在http客户端和es查询参数两层同时设超时：guzzle等客户端控制请求总超时（如timeout=120s），es查询体中需设"timeout":"60s"和"terminate_after":50000，前者防协调节点卡死，后者强制分片截断扫描以降负载。
不能只靠延长 Laravel 层超时来解决 ES 查询超时——ES 超时发生在 HTTP 请求阶段，Laravel 本身不参与 ES 请求的 timeout 控制，必须在客户端 HTTP 配置和 ES 查询参数两层同时干预。
PHP 客户端发起 ES 请求时的超时由谁控制
你用 Guzzle、cURL 或官方 elasticsearch-php 客户端发请求，超时由该 HTTP 客户端决定，和 Laravel 的 max_execution_time、FPM 的 request_terminate_timeout 完全无关。常见错误是改了 php.ini 却发现 ES 还是 30 秒就断——那是因为 Guzzle 默认 timeout 就是 30 秒。
以 elasticsearch-php 为例（v8.x）：
$client = ClientBuilder::create()
->setHosts(['http://es:9200'])
->setHttpClientOptions([
'timeout' => 120.0, // 整个请求最大等待秒数（含连接+读取）
'connect_timeout' => 10.0, // 仅连接建立阶段超时
])
->build();
-
timeout是最关键的，它覆盖了从 TCP 建连到接收完整响应的全过程 -
connect_timeout单独设小一点（如 5–10 秒），能更快暴露网络不通或 DNS 解析失败问题 - 别漏掉
read_timeout（某些旧版 Guzzle 需显式设），新版timeout已包含读取
ES 查询体里必须加 timeout 和 terminate_after
HTTP 客户端超时只是“等多久放弃”，但 ES 后端任务仍在跑。要真正减轻集群压力，必须在查询 JSON 里传 timeout 和 terminate_after：
{
"timeout": "60s",
"terminate_after": 50000,
"query": { "match": { "title": "laravel" } }
}
-
timeout（字符串，如"60s"）：coordinate node 等待所有分片返回的最大时间，超时后直接返回已收到的结果，timed_out字段为true -
terminate_after（整数）：每个分片最多扫描多少文档就停，强制截断搜索范围，真实降低 CPU 和 I/O 消耗 - 二者必须共用：
timeout防止协调节点卡死，terminate_after防止数据节点持续扫描 - 注意：
timeout值不能大于客户端 HTTPtimeout，否则 ES 先返回，客户端却已断连
Laravel 中调用 ES 的典型陷阱
很多项目把 ES 查询写在 Eloquent 模型方法或 Service 类里，看似封装了，实则埋下隐患：
- 没做异常捕获，
GuzzleHttp\Exception\ConnectException或Elasticsearch\Common\Exceptions\NoNodesAvailableException直接炸出 500 - 复用同一个
$client实例但没配置重试策略，一次网络抖动就失败 - 查询中硬编码
size: 10000，触发index.max_result_window限制，报错Result window is too large，而非超时 - 用了
request_cache=true但请求体 JSON 格式稍有差异（比如字段顺序、空格、换行），缓存完全不命中，白白浪费资源
建议在封装层加一层兜底：
try {
$response = $this->client->search([
'index' => 'posts',
'body' => [
'timeout' => '45s',
'terminate_after' => 30000,
'query' => ['match' => ['content' => $q]],
],
]);
} catch (ClientErrorResponseException $e) {
if (str_contains($e->getMessage(), 'timed_out')) {
Log::warning('ES search timeout fallback', ['query' => $q]);
return $this->fallbackSearch($q); // 比如降级查 MySQL 或返回空结果
}
throw $e;
}
别忽略 ES 自身的慢日志和线程池监控
即使你调大了所有 timeout，如果 ES 集群 search 线程池持续 reject，说明根本不是超时设置问题，而是资源已饱和：
- 检查
_nodes/stats/thread_pool，重点关注search.queue_size和search.rejected是否增长 - 打开慢日志：
index.search.slowlog.threshold.query.warn: 5s，看哪些 DSL 真正在拖垮集群 - 用
_tasks?detailed=true&actions=*search*查当前卡住的搜索任务，确认是否被terminate_after截断 - 注意：
terminate_after截断后，hits.total.value不再准确，应用层需判断timed_out === true或terminated_early === true来决定是否提示“结果不完整”
最常被跳过的点是：以为加了 timeout 就万事大吉，却没配 terminate_after，导致 data node 依然在后台扫全量数据——超时只是客户端“不看了”，不是 ES “停了”。
