根本原因是未管理连接生命周期，应复用实例并显式控制开关：单例管理、监听close/error事件、CLI进程重启前主动close、ReactPHP中用状态锁+取消令牌防重复connect、Swoole中每次connect前判断isConnected并手动close、HTTP请求中禁用WebSocket长连接。
PHP 客户端反复 new WebSocket() 导致连接堆积
PHP 本身没有原生 WebSocket 客户端（ext-websocket 是实验性扩展且不维护），实际项目中多用 reactphp/websocket-client 或 textalk/websocket 这类第三方库。反复 new 实例却不 close，连接不会自动释放——TCP socket 会卡在 TIME_WAIT，服务端也持续收到重复 open 事件。
根本原因不是“去重”，而是没管理连接生命周期。解决思路是：**复用实例 + 显式控制开关**。
- 用单例或依赖容器统一管理 WebSocket 客户端实例，避免每次请求都 new
- 连接建立后缓存
$client实例，后续发消息直接调用$client->send() - 务必监听
close和error事件，在回调里置空引用或触发重连逻辑，防止残留 - 若走 CLI 长进程（如 WorkerMan），需在进程重启前主动
$client->close()，否则子进程 fork 后 socket 句柄被复制，连接数翻倍
ReactPHP 中重复 connect() 不触发 reconnect 自动机制
reactphp/websocket-client 的 connect() 返回 Promise，但**它不内置重连逻辑**。手写循环 connect() 而不 cancel 上一个 Promise，会导致多个 pending 连接并存，最终全部成功或超时，客户端看似“连上了好几次”。
正确做法是用状态锁 + 取消令牌：
立即学习“PHP免费学习笔记（深入）”；
- 声明
$isConnecting = false和$pendingConnect = null两个变量 - 每次调用前检查：
if ($isConnecting || $pendingConnect) return; - 发起连接时设
$isConnecting = true，并在 Promise resolve/reject 后重置 - 用
$loop->addTimer(5, fn() => $pendingConnect?->cancel())防止挂起
示例关键片段：
$this->pendingConnect = $connector->connect('wss://api.example.com')->then(
function (ConnectionInterface $conn) {
$this->isConnecting = false;
$this->pendingConnect = null;
// 处理连接
},
function (Exception $e) {
$this->isConnecting = false;
$this->pendingConnect = null;
// 记录错误，可选延迟重试
}
);
使用 Swoole 时 WebSocket::connect() 被多次调用却无报错
Swoole 的 WebSocket\Client 是同步阻塞式，connect() 成功后实例进入已连接状态；但若未判断 $client->isConnected() 就再次调用 connect()，会触发 EALREADY 错误（Linux errno 114），而 Swoole 默认不抛异常，只返回 false —— 你可能根本没捕获到失败，还继续 send，结果消息全丢。
- 每次发送前必须加判断：
if (!$client->isConnected()) { $client->connect(); } - 不要在 onMessage/onClose 回调里直接
connect()，这些回调可能并发触发，需加锁或状态标记 -
connect()超时时间默认 0.5 秒，短连接场景建议设为['timeout' => 3]避免频繁失败 - 连接断开后，Swoole 不自动清理底层 socket，需手动
$client->close()再 new 新实例，否则 fd 泄漏
HTTP 请求里混用 WebSocket 连接的典型陷阱
常见错误：在 Web API 接口（如 Laravel 的 Controller）里每次请求都 new WebSocket 客户端去推消息。PHP-FPM 模式下，每个请求是独立进程，connect() 后进程结束，socket 却没来得及 close，系统级连接堆积，很快触发 Too many open files。
- 绝对禁止在 HTTP 生命周期内建立长连接 WebSocket
- 需要推送时，改用 Redis Pub/Sub 或消息队列通知独立的常驻进程（如 Swoole Server 或 ReactPHP Worker）去发
- 如果非要在 HTTP 中触发，至少用
fastcgi_finish_request()提前返回响应，再异步处理连接和发送（仍需注意资源回收） - 测试阶段用
lsof -i :8080 | wc -l监控连接数，确认没泄漏
真正难的不是“怎么连上”，而是“连上之后怎么不变成僵尸连接”。所有方案都绕不开一个动作：显式 close，以及 close 之前确保没有未完成的 send 或 pending promise。
