根本原因是TCP Nagle算法和缓冲区未刷新，需在connect()前设置open_tcp_nodelay=true；同步客户端无onReceive回调，异步需正确注册，协程模式更可靠；还需排查服务端粘包、协议边界、DNS/SSL延迟及连接池配置。
为什么
收不到实时数据？
根本原因不是网络慢，而是默认启用了 TCP Nagle 算法 + 缓冲区未及时刷新。Swoole 客户端在
后若没显式关闭 Nagle，小包会被合并或延迟发送；服务端发来的数据如果没触发完整帧（比如没换行、没固定长度头），
会一直阻塞或等超时。
检查是否调用了
关闭 Nagle：
，必须在
前设置
避免用
直接读固定字节数（如
），它不保证一次收完一整条消息，容易截断
若服务端用
分隔消息，优先用
（即带分隔符模式），但注意：该模式仅支持
且需服务端配合换行
回调不触发？确认是否在异步模式下正确注册
同步客户端（
构造时传
）根本没有
回调——这是异步/协程客户端才有的机制。很多人把同步写法和事件驱动混用，导致回调永远不执行。
同步模式：只能手动轮询
或用
监听 socket，无事件回调
异步模式：必须用
创建，并通过
注册，且不能在
前注册（会静默失败）
协程模式（推荐）：改用
，直接
不阻塞，无需回调，也不存在“不触发”问题
协程客户端
还是卡住？检查服务端是否粘包或未关闭写缓冲
协程客户端本身无延迟，卡住一定是服务端没发完、没关连接、或协议层没定义清楚边界。比如 HTTP 服务端忘了写
或用 chunked 但没发完；或者自定义协议没加包长头，导致客户端不知道该收多少字节。
Swoole 6.1.1
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
下载
用
或
抓包，确认服务端是否真实发出数据（别只信日志）
服务端如果是
，确保
后没有遗漏
或长度前缀
客户端
加超时：
，避免无限等待；返回
时查
，常见
（ETIMEDOUT）、
（ECONNRESET）
PHP 层面的隐性延迟：DNS 解析、SSL 握手、连接池空闲回收
你以为是 Swoole 的问题，其实可能是 PHP 底层拖了后腿。比如用域名连接时，每次
都走系统 DNS 查询；启用了 TLS 但没复用 session；或者连接池里连接被自动回收，下次又得重连握手。
连接前先做 DNS 缓存：
，后续直连 IP
SSL 场景下，务必开启 session 复用：
连接池场景中，检查
是否过短（默认 60 秒），频繁重建连接会放大延迟
事情说清了就结束。真正卡顿的地方，往往不在
调用本身，而在你没意识到服务端发了什么、网络中间件吞了什么、或者 PHP 进程悄悄做了什么耗时操作。
swoole_clientconnect()recv()set()$client->set(['open_tcp_nodelay' => true])connect()recv()recv(1024)\nrecv(-1, 0)SWOOLE_SOCK_TCPonReceiveswoole_clientSWOOLE_SOCK_SYNConReceiverecv()select()SWOOLE_SOCK_ASYNC$client->on('receive', function() {})connect()Swoole\Coroutine\Clientrecv()recv()Content-LengthtcpdumpWiresharkSwoole\Server$server->send($fd, $data)\nrecv()$client->recv(1024, 1.5)false$client->errCode110104connect()$ip = gethostbyname('api.example.com')$client->set(['ssl_session_reuse' => true])max_idle_timerecv()