最安全位置是每次完整请求处理完毕后，在try-finally中执行sleep()；Guzzle推荐用Middleware在请求发出前动态延时；并发场景需用锁或队列替代sleep()。
php curl 批量请求时 sleep() 放哪儿最安全
直接在 curl_exec() 后、下一次 curl_init() 前加 sleep(1) 是常见但危险的做法——如果某次请求超时或失败，sleep() 仍会执行，反而拉长总耗时；更糟的是，若用 set_time_limit(0) 配合长延时，可能卡住整个脚本。
正确位置是：每次完整请求（含初始化、执行、释放）结束后，且确认本次结果已处理完毕再延时。尤其要注意异常分支是否跳过了延时逻辑。
- ✅ 推荐写法：
try { /* curl 请求 */ } finally { sleep(1); } - ❌ 避免写法：
if ($result) { sleep(1); }—— 失败时不延时，下轮可能触发限流 - ⚠️ 注意：
usleep(500000)比sleep(0.5)更可靠，因为sleep()不支持小数秒（会向下取整为 0）
用 Guzzle + Middleware 控制请求间隔更稳
Guzzle 本身不内置限速，但通过自定义 Middleware 可在每个请求发出前强制等待，比手动 sleep() 更可控，也更容易复用。
核心思路是维护一个上次请求时间戳，在 on_stats 或 before 中检查间隔，不足则补足延时：
立即学习“PHP免费学习笔记（深入）”；
$lastRequestTime = 0; $delayMs = 1000; // 1s $handler = HandlerStack::create(); $handler->push(Middleware::mapRequest(function (Requestinterface $request) use (&$lastRequestTime, $delayMs) { $now = microtime(true) 1000; $elapsed = $now - $lastRequestTime; if ($elapsed < $delayMs) { usleep(($delayMs - $elapsed) 1000); } $lastRequestTime = microtime(true) * 1000; return $request; }));
- ✅ 优势：延时绑定到「请求发出」动作，不受异常或重试干扰
- ⚠️ 注意：别在
on_stats里延时——那是响应返回后，已晚于下个请求发出时机 - ⚠️ 并发场景慎用：单例
$lastRequestTime在多协程（如 swoole）中不安全，需改用Atomic或上下文存储
高频调用被 429 或 503 怎么自动降频
硬编码 sleep(1) 解决不了动态限流问题。API 返回 429 Too Many Requests 或 503 Service Unavailable 时，必须主动延长间隔，否则持续撞墙。
关键不是“设多少”，而是“怎么根据响应反馈调整”：
- ✅ 检查响应状态码，遇到 429 时把延时翻倍（如从 1s → 2s），并记录退避次数
- ✅ 留意响应头：
Retry-After字段优先级最高，值为秒数就直接sleep((int)$retryAfter)，为日期就解析后计算差值 - ❌ 别忽略 503：某些 API 用它代替 429，逻辑上应同等对待
- ⚠️ 注意：退避后要重置计时器，避免因上次延时过长导致后续请求永久低频
并发请求下 sleep() 为什么不管用
用 foreach + sleep() 串行没问题，但一旦改用 curl_multi_exec() 或多进程（pcntl_fork），sleep() 只作用于当前进程/线程，其他并发请求照发不误，限速完全失效。
此时必须换方案：
- ✅
curl_multi场景：用curl_multi_select()配合循环控制，或改用信号量（sem_acquire()）做跨句柄协调 - ✅ 多进程场景：用文件锁（
flock()）或 redis 分布式锁，确保同一时刻只有一子进程发请求 - ✅ 更简单：放弃并发，改用队列（如 redis List +
BRPOP）+ 单 worker 进程，天然串行可控 - ⚠️ 注意：
usleep()在高并发下精度下降明显，10ms 以下延时实际不可靠，别指望靠它压到毫秒级节奏
延时不是加得越细越好，重点是让每次请求真正“错开”，而不是模拟出精确节拍——API 服务端的限流策略往往有窗口滑动、令牌桶等机制，客户端过度拟合反而容易失步。