最常用且可控的微服务聚合方式是用 curl_multi_exec 并发请求，需循环调用至 curlm_ok、为每个请求设 curlopt_timeout_ms≤800、用 curl_multi_getcontent 取响应并及时 curl_close；状态码和 json 结构不一致时，须在 curl_multi_info_read 完成后用 curl_getinfo 获取 http 状态码，非 2xx 直接判失败，成功则 json_decode 并校验错误，字段映射用白名单；不用 file_get_contents 或串行 curl_exec，因其延迟高、无连接复用、易超时；上线前必验空响应、超大 json（>3mb）、非 utf-8 编码，做大小限制与编码转换。
用 curl_multi_exec 并发请求多个微服务接口
单次 API 网关聚合最常用也最可控的方式，就是用 PHP 原生的 curl_multi_exec 同时发起多个 HTTP 请求。它不依赖扩展（如 amphp 或 swoole），兼容 PHP 7.2+，且能精确控制超时、Header 和错误重试。
常见错误现象：curl_multi_exec 返回 CURLM_CALL_MULTI_PERFORM 被忽略，导致响应为空；或没调用 curl_multi_info_read 检查完成状态，结果只拿到部分响应。
- 必须循环调用
curl_multi_exec直到返回CURLM_OK，不能只调一次 - 每个子请求需单独设置
CURLOPT_TIMEOUT_MS（建议 ≤ 800），避免一个慢接口拖垮整条链路 - 用
curl_multi_getcontent($ch)取响应体，别用curl_exec—— 后者在 multi 模式下返回空 - 记得对每个
$ch调用curl_close，否则可能触发 PHP 的资源泄漏警告
foreach ($urls as $key => $url) {
$ch[$key] = curl_init();
curl_setopt($ch[$key], CURLOPT_URL, $url);
curl_setopt($ch[$key], CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch[$key], CURLOPT_TIMEOUT_MS, 800);
curl_multi_add_handle($mh, $ch[$key]);
}
怎么处理微服务返回的 HTTP 状态码和 JSON 结构不一致
真实场景里，订单服务可能返回 200 { "data": {...} }，而用户服务返回 201 { "user": {...} }，甚至有的直接 503 {"error":"timeout"}。网关不能假设结构统一，得做适配。
关键点不是“怎么解析”，而是“什么时候解析”：必须在 curl_multi_info_read 确认请求完成后再取状态码和 body，否则 curl_getinfo($ch, CURLINFO_HTTP_CODE) 可能返回 0。
- 先用
curl_getinfo($ch, CURLINFO_HTTP_CODE)判断是否为 2xx，非 2xx 就当失败，不要硬解 JSON - 对成功响应，用
json_decode(curl_multi_getcontent($ch), true)，并检查json_last_error()是否为 0 - 字段映射建议用白名单数组，比如
['order' => 'data', 'user' => 'user']，而不是写一堆if (isset($res['data'])) ... else if (isset($res['user'])) ...
为什么不用 file_get_contents 或单个 curl_exec 串行调用
串行等于把总延迟变成各服务耗时之和。假设三个服务平均响应 300ms，串行就是 900ms+，用户明显感知卡顿；而并发通常压在 350ms 内 —— 取决于最慢那个。
更隐蔽的问题是连接复用：file_get_contents 默认不复用 TCP 连接，每次新建 socket，遇到 DNS 解析慢或 TLS 握手开销大的服务（比如跨云厂商），性能断崖式下跌。
-
curl_multi天然支持 connection reuse，同一 host 的多个请求可共享一个 keep-alive 连接 - PHP-FPM 下，串行调用容易触发
max_execution_time超时，尤其加了重试逻辑后 - 若某服务不可用，串行会阻塞后续所有请求；并发模式下可设 fallback 值（如空数组）并继续聚合
上线前必须验证的两个边界条件
多数人测通了 200 就上线，但生产环境垮掉往往发生在边界上：空响应体、超大 JSON（>2MB）、服务返回非 UTF-8 编码（比如 GBK）、DNS 轮询导致 IP 变更。
- 用
curl_getinfo($ch, CURLINFO_SIZE_DOWNLOAD)检查响应体大小，超过阈值（如 3MB）直接丢弃并记录告警，防止 OOM - 用
mb_detect_encoding(curl_multi_getcontent($ch), ['UTF-8', 'ISO-8859-1'], true)验证编码，非 UTF-8 就mb_convert_encoding转换，否则json_decode静默失败
真正麻烦的从来不是“怎么合并”，而是“怎么扛住不稳定的下游”。网关层没做超时隔离、没验编码、没控响应体积，出问题时连日志都看不出是哪个服务吐了非法数据。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
