Workerman 4 WebSocket广播需跨进程实现全量推送，推荐GatewayWorker或Redis Pub/Sub方案；单进程遍历易致性能瓶颈、消息丢失，须过滤无效连接、批量序列化、分片压缩及添加节流与监控兜底。
Workerman 4 的 WebSocket 广播，用 foreach($connection->worker->connections as $client) 遍历发送，看似简单，但在高并发下容易成为性能瓶颈——连接数过千时，单次广播可能卡住整个进程、丢消息、延迟飙升。关键不在“能不能发”，而在“怎么发得稳、快、不垮”。
单进程广播的天然限制与风险
Workerman 默认每个 Worker 进程只维护自己进程内的连接列表。$connection->worker->connections 只包含当前进程的客户端，其他进程里的连接完全不可见。这意味着：
- 启动 4 个进程时，每次广播只触达约 1/4 的在线用户，其余连接收不到消息
- 若业务逻辑（如查数据库、调 API）混在 onMessage 里，会阻塞事件循环，导致后续连接握手失败或心跳超时断连
- 遍历 + send() 是同步操作，连接越多耗时越长；万级连接下一次广播可能耗时数百毫秒，严重拖慢吞吐
必须跨进程：用 GatewayWorker 或 Redis Pub/Sub
真正可用的广播，必须让所有 Worker 进程都能把消息推给全部在线用户。生产环境推荐两种成熟路径：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- GatewayWorker 架构：官方推荐方案。拆为 Gateway（负责连接、心跳、协议解析）、BusinessWorker（纯异步业务处理）、Register（节点注册）。广播由 Gateway 统一转发，天然支持全网广播、按群组/UID 推送，且不阻塞业务进程
-
Redis Pub/Sub + Channel 组件：轻量替代。BusinessWorker 收到消息后 publish 到 Redis 频道，各 Worker 进程订阅该频道并触发本地广播。需配合
Workerman\Lib\Channel实现进程间通信，避免重复订阅和消息堆积
广播过程本身可优化的细节
即便走跨进程方案，广播环节仍有提升空间：
- 发送前过滤无效连接：
if ($client->isClosed() || !$client->isWebSocketConnection()) { continue; }，避免向已断开或非 WebSocket 连接写数据引发 warning - 批量序列化一次，而非每次 send 前都 json_encode：尤其当广播内容含时间戳、用户信息等动态字段时，提前组装好字符串更省 CPU
- 对大消息启用分片或压缩：WebSocket 单帧默认有 64MB 限制，超长文本建议 gzip 后 base64 编码，客户端解压；或拆成多帧发送（需客户端配合）
- 高频广播场景加节流：例如聊天室打字提示每秒最多发 1 条，用 Timer::add 定时器聚合多条消息统一推送
监控与兜底不能少
广播不是“发了就完事”。真实线上需关注：
- 记录每次广播的连接数、耗时、失败数（比如 send() 返回 false 时记日志）
- 定期检查
$worker->connections数量突降——可能是心跳异常或进程崩溃 - 设置全局广播超时：用
Connection::$defaultMaxSendBufferSize = 1024 * 1024;防止缓冲区爆满卡死进程 - 准备降级开关：当广播失败率 >5%，自动切到“仅推活跃用户（最近 30 秒有消息）”模式，保核心链路
