最基础的广播方式是遍历所有fd并调用$server->push()，但高并发下易成性能瓶颈；优化需减少阻塞、过滤无效连接、协程分批异步发送、控制消息大小与频率，并善用swoole 5.1+内置连接管理机制。
直接遍历所有 fd 并调用 $server->push() 是最基础的广播方式，但高并发下容易成为性能瓶颈。关键不在“能不能发”，而在“怎么发得稳、发得快、不拖垮服务”。优化的核心是减少阻塞、规避无效连接、控制并发压力。
避免全量同步遍历，改用协程分批异步发送
单次遍历数万连接会阻塞当前协程，尤其在消息体较大或网络延迟波动时。Swoole 5.1+ 支持原生协程，应主动拆分任务：
- 将
$server->connections切片（如每批 30–50 个 fd），每批启动一个独立协程处理 - 协程内逐个检查
$server->isEstablished($fd)，仅对有效连接调用push() - 避免在主逻辑中使用
foreach+sleep或密集循环，改用co::sleep(0)让出调度权
提前过滤无效连接，跳过状态异常的 fd
不是所有记录在 connections 中的 fd 都可安全推送。连接可能已断开但服务端尚未触发 close 回调（例如客户端强退、心跳超时未清理）：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 必须调用
$server->isEstablished($fd)，它比手动查getClientInfo()更轻量且线程/协程安全 - 不要依赖
getClientInfo()的返回值做判断——该方法在连接刚断开瞬间仍可能返回非空结果 - 若业务允许，可配合 Redis 缓存在线状态（如 fd → uid 映射 + TTL），双重校验后再推送
控制广播频率与消息体大小
高频小包或低频大包都会影响吞吐。真实场景中需权衡实时性与系统负载：
- 对非紧急通知（如系统公告），可合并多条消息为 JSON 批量推送，降低调用次数
- 单次
push()消息建议控制在 64KB 以内；超过则触发分帧，增加协议开销 - 使用
$server->stats()定期观察connection_num和tasking_num，若 task 队列持续积压，说明协程并发数或批大小需下调
利用 Swoole 内置连接池与连接管理机制
Swoole 5.1+ 已深度集成连接生命周期管理，无需自己维护 SplObjectStorage 或数组缓存：
- 直接使用
$server->connections（返回 Generator，内存友好） - 禁用
heartbeat_check_interval默认值（60s），设为 15–30s 加速断连感知 - 开启
'open_websocket_protocol' => true和'websocket_subprotocol' => 'chat'可提升帧解析效率
