高频调用第三方api防限流应优先用usleep而非sleep，因usleep可精确到微秒（通常稳定毫秒级），支持匀速发送以匹配秒级限流策略；sleep最小单位为秒，过于粗粒度，易浪费配额或触发限流。
php接口调用前加延时该用 usleep 还是 sleep
直接结论：高频调用第三方API防限流，优先用 usleep，不是 sleep。因为 sleep 最小单位是秒，而多数接口限流策略按秒级请求数（如 10次/秒），光等1秒太粗，容易浪费配额或触发突发限流。
usleep 能精确到微秒（实际精度受系统调度影响，但通常可稳定控在毫秒级），适合做“匀速发送”——比如每100ms发1次，就能严格卡在10次/秒。
-
sleep(1)会阻塞整整1秒，期间无法做任何事，也不利于并发控制 -
usleep(100000)= 100ms，更细粒度，配合循环可实现平滑节流 - 注意：
usleep参数是微秒，别错写成毫秒（比如usleep(100)只停0.1ms，基本无效）
怎么在 Guzzle 或 curl 请求之间插 usleep
关键不是“能不能加”，而是“加在哪”——必须加在真正发起请求之前，且每次请求前都执行。如果封装了统一请求函数，这是最安全的位置。
示例（Guzzle 场景）：
立即学习“PHP免费学习笔记（深入）”；
$client = new GuzzleHttpClient(); $requests = [...]; // 待发请求列表 foreach ($requests as $req) { usleep(150000); // 每次请求前等150ms → 约6.6次/秒 $response = $client->request('GET', $req['url'], $req['options']); // 处理响应... }curl 同理，在 curl_exec() 前加 usleep。切忌加在 curl_init() 后、curl_setopt() 前——那只是初始化开销，不构成真实请求间隔。
- 别在 try/catch 外层统一加延时，失败重试时可能重复等待，打乱节奏
- 如果用了异步并发（如 Guzzle promise），
usleep会阻塞整个进程，此时应改用事件循环或队列控制 - 某些云函数环境（如阿里云FC）对长时间阻塞敏感，
usleep超过数秒可能被强制终止
usleep 会影响脚本超时和内存吗
会，但只影响执行时间，不影响内存占用。usleep 是让 PHP 进程挂起，CPU 不跑，但脚本仍在运行状态，所以 max_execution_time 计时器照常走。
比如设了 set_time_limit(30)，你连续 usleep(1000000)（1秒）执行25次，就已耗掉25秒，剩下5秒留给实际网络IO和逻辑处理——很容易超时。
- 务必在延时前检查剩余执行时间：
ini_get('max_execution_time')和microtime(true)配合估算 -
usleep不释放已申请的内存，大数组+长延时容易触发 OOM，尤其在 CLI 模式下无自动 GC 触发 - Web SAPI（如 apache mod_php）中，长
usleep会占住 worker 进程，影响并发能力，慎用于用户直触接口
比 usleep 更靠谱的限流方案有哪些
单靠 usleep 是“土办法”，适用于临时脚本、低频任务或调试阶段。真要上线，建议换更稳的方案。
推荐顺序：令牌桶 > 滑动窗口计数 > 固定窗口 + usleep 回退。
- 用
redis实现令牌桶（如INCR+EXPIRE组合），能跨进程限流，且支持突发流量缓冲 - 简单场景可用
apcu_add做内存级计数（注意 APCu 在 CLI 下默认不共享，需配置apc.enable_cli=1） - 别依赖
file_put_contents写文件计数——高并发下文件锁会成为瓶颈，还容易因异常中断导致计数错乱
真正难的不是加延时，而是判断“该不该延”“延多久”——这需要解析接口返回的 X-RateLimit-Remaining 和 X-RateLimit-Reset 头，动态调整间隔。硬写 usleep 容易在配额恢复后仍傻等。