PHP原生stream_socket_client高并发卡死主因是同步阻塞IO，无事件驱动机制，超时不可控且无真正取消机制；Swoole Client基于epoll/kqueue实现异步非阻塞，单进程可支撑数千连接。
stream_socket_client 为什么在高并发下容易卡死
PHP原生 stream_socket_client 是同步阻塞的，每次调用都会让当前协程/进程停在IO上，直到连接建立、数据收完或超时。哪怕你设了 stream_set_timeout，底层仍可能因系统TCP重传、DNS解析未返回等陷入不可控等待；更糟的是，它没有真正的“取消”机制，超时后 socket 可能还挂在内核里没清理干净。Swoole 的 Swoole\Client（尤其是异步模式）由 epoll/kqueue 驱动，连接、读写都注册为事件，不占 PHP 执行线程，一个进程可轻松维持数千连接。
Swoole Client 的 waitall 和 stream_get_contents 的行为差异
stream_get_contents 默认只读缓冲区当前可用字节，遇到 TCP 粘包或分片就只取一部分，必须配合循环 + feof/stream_select 手动拼包；而 Swoole\Client->recv($length, $flag) 支持 SWOOLE_KEEP 和 SWOOLE_WAITALL 标志：$client->recv(1024, SWOOLE_WAITALL) 会一直等到收满 1024 字节才返回（或连接断开），避免手动 while 循环和边界判断出错。
- UDP 场景下，
stream_socket_recvfrom无法保证单次收全大包（如 >8192 字节），Swoole\Client则无此限制 -
stream_socket_sendto不检查目标是否可达，发完即认为成功；Swoole\Client->send()返回值明确区分“已写入内核缓冲区”和“发送失败”，且支持回调监听实际送达状态
SSL 连接复用与证书验证的坑
PHP stream 的 stream_context_create(['ssl' => [...]]) 每次 stream_socket_client 都新建 TLS 握手，无法复用 session ticket；而 Swoole\Client 在启用 SWOOLE_SSL 后，只要不主动 close()，后续 connect() 会自动复用 SSL session，大幅降低握手开销。但注意：Swoole\Client 默认不校验服务端证书（类似 verify_peer => false），必须显式设置 $client->set(['ssl_cert_file' => '/path/to/cert.pem']) 并开启 ssl_verify_peer => true，否则存在中间人风险。
- FPM/Apache 环境下只能用
Swoole\Client同步模式，异步回调（onConnect/onReceive）会被忽略 - CLI 下用异步模式时，必须调用
Swoole\Event::wait()启动事件循环，否则回调永远不会触发
UDP connect() 解决串包问题的实际效果
PHP 原生 UDP socket 是无连接的，stream_socket_sendto 发给 A 服务器，stream_socket_recvfrom 却可能收到 B 服务器的响应（尤其在多客户端共用同一端口时）。Swoole\Client 支持对 UDP socket 调用 connect()，将 socket 绑定到指定地址+端口，之后 recv() 只接收该对端发来的数据，彻底规避串包。这个行为在 PHP stream 层面根本不存在对应能力——你只能靠应用层加消息头+ID 来过滤，成本高且不可靠。
立即学习“PHP免费学习笔记（深入）”；
真正难处理的不是“怎么选”，而是混用场景：比如你在 Swoole HTTP Server 里用 stream_socket_client 调第三方 API，协程会被阻塞，整个 worker 就卡住；这时候必须换 Swoole\Coroutine\Http\Client 或 Swoole\Client，否则并发数上不去。协程 IO 和同步 IO 不能共存于同一线程，这是最常被忽略的底层约束。
