广播没有开箱即用的broadcast()函数，必须手动维护连接集合并遍历发送，且每次发送前须检查连接状态以避免异常。
广播不是调用一个现成的 broadcast() 就完事
很多初学者看到文档里出现 broadcast() 就以为这是标准 API，结果在 websockets（Python）、think-swoole4.x 或原生 javax.websocket 里死活找不到——因为根本不存在全局可用的、开箱即用的 broadcast() 函数。它要么是某个封装库的私有方法（比如旧版 think-swoole3），要么是示例代码里手写的循环逻辑。
真正能跨平台、跨框架落地的，只有「自己维护连接集合 + 遍历发送」这一条路。关键不在“有没有函数”，而在“怎么安全地遍历”和“怎么避免发到已断开的连接上”。
- Java（Tyrus/Jetty）必须用
ConcurrentHashMap.newKeySet()或CopyOnWriteArraySet，不能用普通HashSet，否则并发修改会抛ConcurrentModificationException - Python
websockets库里，connected_clients必须是set或weakref.WeakSet，否则连接关闭后对象残留，导致内存泄漏 - Node.js +
ws模块时，别直接用clients.forEach()发送，要配合ws.readyState === WebSocket.OPEN判断，否则会触发WebSocket is not open错误
遍历发送前必须检查连接状态，否则大量 Connection closed 报错
WebSocket 连接随时可能因网络抖动、客户端关页、心跳超时而断开，但服务端不会立刻感知。如果你不加判断就对所有记录中的连接调用 send()，大概率会遇到：
ConnectionClosedError（Python websockets）java.io.IOException: Broken pipe（Java Tyrus）WebSocket is not open: readyState 0（Node.js ws）
正确做法是在每次发送前做轻量级状态检查：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Python：
if websocket.open:或捕获ConnectionClosedOK/ConnectionClosedError异常并清理集合 - Java：
if (session.isOpen()) { session.getBasicRemote().sendText(msg); } - Node.js：
if (ws.readyState === WebSocket.OPEN) ws.send(msg)，且建议搭配ws.isAlive心跳标记（见官方ws示例）
Spring Boot + STOMP 的 /topic/xxx 不是“自动广播”，而是靠消息代理转发
很多人以为在 Spring Boot 里配置了 @EnableWebSocketMessageBroker 和 enableSimpleBroker("/topic")，再调用 simpMessagingTemplate.convertAndSend("/topic/broadcast", msg) 就是“服务器直发”，其实不是。这条消息先进入内嵌的 SimpleBroker 或外接的 RabbitMQ/Redis，再由 broker 推送给所有订阅了 /topic/broadcast 的客户端。
这意味着：
- 你无法在发送时拿到当前在线客户端数量或 ID 列表
- 如果客户端没主动
subscribe("/topic/broadcast")，就收不到——这和“向所有连接发消息”的原始需求不等价 - 若需精准控制（比如排除某类用户、按标签分组），得换用
@MessageMapping+ 手动管理 session，绕过 broker
Swoole 的 getClientList() 看似方便，但只返回 TCP 连接 ID，不等于 WebSocket 会话
在 ThinkPHP8 + think-swoole4.x 中，有人试图用 $server->getClientList() 获取全部客户端，再逐个 $server->push($fd, $msg)。这条路能跑通，但有严重隐患：
-
getClientList()返回的是底层 TCP 连接 ID（$fd），不是 WebSocket 会话对象；它不区分协议层是否完成 WebSocket 握手，未握手的连接也会被列出来 - 如果用了多 Worker 进程（默认），
getClientList()在 SWOOLE_BASE 模式下只返回当前 Worker 的连接，漏掉其他 Worker 的客户端 - 更稳妥的做法是：在
onOpen时把$fd存进 Redis 或 Swoole\Table，再用foreach遍历这个集中式会话表，同时结合$server->exist($fd)做存活校验
广播这件事，没有银弹。最不可靠的是依赖某个框架“宣称支持”的方法，最可靠的是亲手管住连接生命周期、每次发送前做状态确认、出错时及时清理——这些动作看起来琐碎，但恰恰是线上系统稳定推送的底线。
