php curl post限速需用curlopt_max_send_speed_large（发送）和curlopt_max_recv_speed_large（接收），单位字节/秒，值须为int64类型，0为不限速，负数报错；实际为平均速率，波动±15%。
PHP cURL POST 请求如何限速
PHP 本身不提供直接的「限速」参数，但 curl_setopt() 支持 CURLOPT_MAX_SEND_SPEED_LARGE 和 CURLOPT_MAX_RECV_SPEED_LARGE，可对上传/下载速率强制节流。注意：这两个选项仅在 libcurl ≥ 7.15.5 且编译时启用了 CURL_DISABLE_HTTP 以外的协议支持时才生效（绝大多数生产环境满足）。
常见误操作是把限速值设为整数（如 1024），实际必须用 int64 类型——PHP 中需用 (int)1024 或更稳妥地调用 intval()，否则在 32 位环境可能溢出或被忽略。
-
CURLOPT_MAX_SEND_SPEED_LARGE控制 POST 请求体发送速率（单位：字节/秒），对application/x-www-form-urlencoded或小 JSON 体较明显 -
CURLOPT_MAX_RECV_SPEED_LARGE控制响应体接收速率，适合防止大文件响应拖垮本地内存 - 速率值设为
0表示不限速；设为负数会导致 cURL 返回CURLE_UNKNOWN_OPTION - 限速是「平均速率」，不是瞬时带宽控制，cURL 内部通过延迟发送/接收批次实现，实际波动 ±15%
用 stream_context 实现简单请求限速（无 cURL 场景）
若项目禁用 cURL（如某些共享主机），只能用 file_get_contents() + stream_context_create()，但它**不支持传输层限速**。能做的只有超时控制和连接级防护：
-
http[timeout]限制整个请求耗时，不能等效于速率控制 -
http[ignore_errors]配合http[max_redirects]可防重定向风暴，间接降低并发压力 - 真正想限速，必须自己拆分数据、加
usleep()：比如把一个 1MB 的 POST body 拆成 10KB 分块，每发一块后usleep(10000)（即强制 10ms 间隔），再拼接成完整请求
这种做法破坏 HTTP 语义，服务端可能拒绝分块未按规范编码的请求，仅适用于调试或极简内部接口。
立即学习“PHP免费学习笔记（深入）”；
服务端反向限速比客户端更可靠
在 PHP 客户端硬限速，本质是“自缚手脚”。更合理的做法是在目标接口侧做速率控制，例如用 Redis 记录 IP + 接口维度的请求时间戳，每次请求前 zremrangebyscore 清过期记录，再 zcard 判是否超限。客户端只需处理 429 Too Many Requests 响应：
- 检查响应头
Retry-After，有则休眠对应秒数 - 无该头时建议指数退避：
usleep(pow(2, $retry_count) * 100000) - 避免在客户端重复实现令牌桶逻辑，容易因时钟不同步或并发导致误判
尤其当多个 PHP 进程共用同一出口 IP 时，客户端各自限速毫无意义，服务端统一收敛才是关键。
别忽略 DNS 和连接复用对“感知速率”的影响
很多人测出 POST 很慢，第一反应是限速，其实常是 curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 300) 太短，或未启用连接复用，导致每次请求都重走 DNS 解析 + TCP 握手 + TLS 协商。
- 加
CURLOPT_TCP_FASTOPEN（需 libcurl ≥ 7.49.0 + Linux 3.7+）可减少首次连接耗时 - 复用 cURL handler：创建一次
curl_init()，多次curl_setopt()+curl_exec()，避免反复初始化开销 - DNS 缓存靠
CURLOPT_DNS_CACHE_TIMEOUT（默认 120 秒），设为-1表示永久缓存（内网场景安全）
这些优化带来的耗时下降，往往比单纯限速更有实际价值——毕竟你通常想的是「稳速发完」，而不是「故意卡慢」。
