根本原因是TCP Nagle算法和缓冲区未刷新，需在connect()前设置open_tcp_nodelay=true；同步客户端无onReceive回调，异步需正确注册，协程模式更可靠；还需排查服务端粘包、协议边界、DNS/SSL延迟及连接池配置。

为什么 swoole_client 收不到实时数据？

根本原因不是网络慢，而是默认启用了 TCP Nagle 算法 + 缓冲区未及时刷新。Swoole 客户端在 connect() 后若没显式关闭 Nagle，小包会被合并或延迟发送；服务端发来的数据如果没触发完整帧（比如没换行、没固定长度头），recv() 会一直阻塞或等超时。

• 检查是否调用了 set() 关闭 Nagle：$client->set(['open_tcp_nodelay' => true])，必须在 connect() 前设置
• 避免用 recv() 直接读固定字节数（如 recv(1024)），它不保证一次收完一整条消息，容易截断
• 若服务端用 \n 分隔消息，优先用 recv(-1, 0)（即带分隔符模式），但注意：该模式仅支持 SWOOLE_SOCK_TCP 且需服务端配合换行

onReceive 回调不触发？确认是否在异步模式下正确注册

同步客户端（swoole_client 构造时传 SWOOLE_SOCK_SYNC）根本没有 onReceive 回调——这是异步/协程客户端才有的机制。很多人把同步写法和事件驱动混用，导致回调永远不执行。

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

• 同步模式：只能手动轮询 recv() 或用 select() 监听 socket，无事件回调
• 异步模式：必须用 SWOOLE_SOCK_ASYNC 创建，并通过 $client->on('receive', function() {}) 注册，且不能在 connect() 前注册（会静默失败）
• 协程模式（推荐）：改用 Swoole\Coroutine\Client，直接 recv() 不阻塞，无需回调，也不存在“不触发”问题

协程客户端 recv() 还是卡住？检查服务端是否粘包或未关闭写缓冲

协程客户端本身无延迟，卡住一定是服务端没发完、没关连接、或协议层没定义清楚边界。比如 HTTP 服务端忘了写 Content-Length 或用 chunked 但没发完；或者自定义协议没加包长头，导致客户端不知道该收多少字节。

• 用 tcpdump 或 Wireshark 抓包，确认服务端是否真实发出数据（别只信日志）
• 服务端如果是 Swoole\Server，确保 $server->send($fd, $data) 后没有遗漏 \n 或长度前缀
• 客户端 recv() 加超时：$client->recv(1024, 1.5)，避免无限等待；返回 false 时查 $client->errCode，常见 110（ETIMEDOUT）、104（ECONNRESET）

PHP 层面的隐性延迟：DNS 解析、SSL 握手、连接池空闲回收

你以为是 Swoole 的问题，其实可能是 PHP 底层拖了后腿。比如用域名连接时，每次 connect() 都走系统 DNS 查询；启用了 TLS 但没复用 session；或者连接池里连接被自动回收，下次又得重连握手。

• 连接前先做 DNS 缓存：$ip = gethostbyname('api.example.com')，后续直连 IP
• SSL 场景下，务必开启 session 复用：$client->set(['ssl_session_reuse' => true])
• 连接池场景中，检查 max_idle_time 是否过短（默认 60 秒），频繁重建连接会放大延迟

事情说清了就结束。真正卡顿的地方，往往不在 recv() 调用本身，而在你没意识到服务端发了什么、网络中间件吞了什么、或者 PHP 进程悄悄做了什么耗时操作。