17370845950

在共享主机环境下，php 脚本中连续发起多个 curl post 请求时，即使单次请求未超时，整体脚本仍可能因累计执行时间超过 120 秒而触发 `maximum execution time exceeded` 错误——根本原因在于 php 脚本生命周期持续计时，而非按 http 请求独立计时。

你遇到的问题并非 cURL 请求本身“被合并”，而是 PHP 脚本的总执行时间（从

关键误区澄清：
✅ curl_exec() 是同步阻塞调用，脚本会原地等待响应返回后才继续下一行；
❌ 这不是“并发请求”，也不存在服务端“合并”逻辑——超时完全由 PHP 解释器的 max_execution_time 控制。

✅ 推荐解决方案（按优先级排序）

1. 引入可控间隔（快速缓解）

在循环内添加 sleep(1) 可降低瞬时负载，并为服务器响应留出缓冲空间，同时小幅延长总可用时间（因部分时间不计入 CPU 执行，但注意：sleep() 仍会计入 max_execution_time）。更稳妥的做法是结合 set_time_limit(0)（若主机允许）：

// ⚠️ 仅在支持且安全的前提下使用（部分共享主机禁用）
@set_time_limit(0); // 尝试取消脚本时间限制（需 host 开放）

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,           // 单次 cURL 最长等待 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);

    // ✅ 主动休眠 0.5~1 秒，减轻服务端压力并提升稳定性
    usleep(500000); // 0.5 秒，比 sleep(1) 更精细
}

2. 异步解耦（长期推荐）

将耗时任务移出 Web 请求生命周期：

• 使用队列（如 Redis + Worker）或数据库标记待处理任务；
• 前端通过 AJAX 轮询或 WebSocket 获取进度；
• 后台 CLI 脚本（无超时限制）定时消费任务。

3. 分页与限流适配

检查目标接口是否支持更高效的数据获取方式（如流式响应、分批压缩、增量同步），避免单次请求固定耗时过长。

⚠️ 注意事项

• sleep() 和 usleep() 仍计入 max_execution_time（PHP ≥ 7.1 默认如此），不能根本解决时间限制，仅作辅助优化；
• 共享主机通常禁用 set_time_limit()，请先测试 ini_get('max_execution_time') 和 ini_set('max_execution_time', ...) 是否生效；
• 目标接口耗时 32+/50 秒属于严重性能瓶颈，建议协同后端优化逻辑（如异步处理、缓存预热、SQL 索引优化）；
• 始终校验 curl_exec() 返回值，避免 false 导致后续 json_decode(null) 异常。

综上，这不是 cURL 的设计缺陷，而是 Web SAPI 模式下资源约束的必然体现。短期靠间隔+超时控制缓解，长期务必推动架构向异步、解耦演进。