在共享主机环境下，php 脚本执行时间受限（如 120 秒），若循环内连续发起耗时较长的 curl post 请求，总执行时间会累加而非并行，极易触发“maximum execution time exceeded”致命错误。本文提供优化方案与关键实践建议。
你遇到的问题本质是同步阻塞式请求的累积耗时超限，而非单次请求超时。虽然每次 curl_exec() 是独立 HTTP 请求，但 PHP 脚本本身是单线程顺序执行的：第一个请求耗时 32 秒、第二个 50 秒，仅两次循环就已占用 82 秒；当循环扩大（如 i <= 200 实际执行 3 次：0、100、200），总耗时轻松突破 120 秒限制，导致脚本被强制终止。
你的原始代码存在两个关键隐患：
- 无超时控制：未设置 CURLOPT_TIMEOUT 或 CURLOPT_CONNECTTIMEOUT，cURL 可能因网络或服务端响应慢而无限等待；
- 高频密集调用：目标服务器可能对短时间内的重复 POST 请求实施限流或主动延迟响应（尤其在共享环境），加剧整体耗时。
✅ 推荐解决方案如下：
✅ 1. 主动添加请求间隔（轻量有效）
在循环内插入 sleep(1) 是快速缓解策略，可显著降低服务端压力与连接竞争：
for ($i = 0; $i <= 200; $i += 100) {
$postData = [
'start' => $i,
'end' => $i + 100
];
$ch = curl_init('https://your-server.com/endpoint');
curl_setopt_array($ch, [
CURLOPT_POST => TRUE,
CURLOPT_RETURNTRANSFER => TRUE,
CURLOPT_TIMEOUT => 60, // 单次请求最长等待 60 秒
CURLOPT_CONNECTTIMEOUT => 10, // 连接阶段超时 10 秒
CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
CURLOPT_POSTFIELDS => json_encode($postData)
]);
$response = curl_exec($ch);
if ($response === false) {
error_log('cURL Error: ' . curl_error($ch));
continue;
}
$responseData = json_decode($response, true);
echo $response . "\n";
curl_close($ch);
sleep(1); // ⚠️ 关键：强制间隔 1 秒，避免请求洪峰
}✅ 2. 更健壮的替代方案（推荐用于生产）
若业务允许，应彻底规避「前端浏览器直触长耗时任务」模式：
- ✅ 改用异步队列：通过 AJAX 触发任务创建 → 后端将分片任务写入 Redis/DB → 启动后台 Worker（CLI 模式）执行，不受 Web 执行时间限制；
- ✅ 分页轮询反馈：前端发起一次请求启动批量任务，返回 task_id；后续通过独立接口轮询状态，提升用户体验与系统稳定性；
- ✅ 服务端流式响应（Streaming）：若需实时反馈，可用 flush() + ob_flush() 分段输出，但需确保 Web 服务器（如 Apache/Nginx）未缓冲响应。
⚠️ 注意事项
- sleep() 不能解决根本瓶颈，仅是权宜之计；长期应重构为异步架构；
- 共享主机通常禁用 set_time_limit(0)，不可依赖；
- 目标接口逻辑耗时 32–50 秒，说明存在性能瓶颈（如未索引查询、大文件处理等），建议在服务端做性能分析与优化；
- 始终校验 curl_exec() 返回值，避免 false 导致后续 json_decode(null) 等意外错误。
通过合理控制请求节奏 + 显式超时 + 架构升级，即可在资源受限环境中稳定完成批量数据提交任务。
