swoole_http_client调用send()无反应是因为默认同步阻塞，需显式配置timeout并运行于EventLoop；推荐改用Co\Http\Client，其在Co\run()中天然异步，send()后须调recv()或捕获异常确认结果。
为什么 swoole_http_client 调用 send() 后没反应？
因为默认是同步阻塞行为，不是异步——哪怕你用的是 swoole_http_client，不显式开启异步模式，send() 会等响应回来才返回，根本没走事件循环。
必须在创建客户端时传入 ['timeout' => -1]（或任意正数），并确保在 EventLoop 中运行；否则 on('receive') 根本不会触发。
-
swoole_http_client的异步能力依赖底层reactor线程和eventloop，脱离Swoole\Event::wait()或Co\run()环境就退化为同步 - PHP-FPM 或 CLI 直接 new 客户端调
send()→ 没回调、无报错、静默失败 - 推荐改用
Co\Http\Client（协程版），它在Co\run()下天然异步，语义更直白，send()不阻塞当前协程
Co\Http\Client 发请求后怎么确保数据发出去了？
协程客户端的 send() 是立即返回的，但不代表已发出——它只把请求写入缓冲区，真发送依赖底层 socket 写事件。网络卡顿或对端接收慢时，send() 成功 ≠ 数据抵达服务端。
真正可靠的判断点是 recv() 返回值或捕获异常，而不是 send() 的返回布尔值。
-
send()返回true：仅表示请求已入发送队列，可能还在内核 socket 缓冲区里 - 必须调
recv()并检查返回数组中的headers和body，或捕获Swoole\Coroutine\Http\Client\Exception - 超时控制靠
set(timeout => 5.0)，不是靠send()参数；设太短会导致频繁ETIMEOUT - 若只发不管回包（如日志上报），建议加
go(function () { ... })包一层，避免阻塞主流程，但仍需在协程内调recv()或设keep_alive = false减少连接维持开销
异步发数据时 onWrite 和 onBufferFull 怎么用？
这两个回调只在 swoole_client（TCP/UDP 原生客户端）中有效，swoole_http_client 和 Co\Http\Client 不暴露底层 socket 缓冲状态，所以别在这俩上浪费时间配 onBufferFull。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
如果你真在用 swoole_client 异步发二进制流或自定义协议，才需要关注：
-
onBufferFull触发说明发送缓冲区满（默认 1MB），继续send()会失败，此时应暂停投递、等onWrite -
onWrite表示内核已腾出空间，可安全继续send()，但注意它不保证本次发送完成，只是“可以再试” - 误把
onBufferFull当作“对方处理不过来”是常见误解——实际往往是本地网卡或路由拥塞，和业务逻辑无关 - 高吞吐场景下，建议调大
buffer_high_watermark配置（如2 * 1024 * 1024），减少回调抖动
HTTP 异步客户端并发 1000+ 请求崩了？
崩点通常不在代码逻辑，而在系统级限制：文件描述符不足、TIME_WAIT 连接堆积、DNS 查询阻塞。
Co\Http\Client 默认复用连接（keep_alive = true），但 DNS 解析仍可能同步阻塞——尤其批量请求不同域名时。
- 先用
ulimit -n确认系统允许打开的 fd 数，Swoole 默认每个 client 占 2 个 fd（socket + dns），1000 并发至少要 3000+ 余量 - DNS 必须用
getaddrinfo异步版本，即启用Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，否则Co\Http\Client在首次解析域名时会同步卡住 - 避免短连接风暴：
set(['keep_alive' => false])+ 高频新建 client → 大量CLOSE_WAIT和端口耗尽，应优先复用 client 实例 - 真实压测前，用
ss -s和netstat -ant | grep TIME_WAIT | wc -l看连接态，比看 PHP 报错更有价值
事情说清了就结束。
