17370845950

在共享主机环境下，php 脚本执行时间受限（如 120 秒），若循环内连续发起耗时较长的 curl post 请求，总执行时间会累加而非并行，极易触发“maximum execution time exceeded”致命错误。本文提供优化方案与关键实践建议。

你遇到的问题本质是同步阻塞式请求的累积耗时超限，而非单次请求超时。虽然每次 curl_exec() 是独立 HTTP 请求，但 PHP 脚本本身是单线程顺序执行的：第一个请求耗时 32 秒、第二个 50 秒，仅两次循环就已占用 82 秒；当循环扩大（如 i

你的原始代码存在两个关键隐患：

1. 无超时控制：未设置 CURLOPT_TIMEOUT 或 CURLOPT_CONNECTTIMEOUT，cURL 可能因网络或服务端响应慢而无限等待；
2. 高频密集调用：目标服务器可能对短时间内的重复 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) 等意外错误。

通过合理控制请求节奏 + 显式超时 + 架构升级，即可在资源受限环境中稳定完成批量数据提交任务。