私聊和群聊的核心差异在于服务端消息路由逻辑而非协议层；需通过clients映射表和targetId字段实现定向分发，严格校验type、targetId、连接状态及fromId来源。
私聊和群聊的核心差异不在协议层，而在服务端消息路由逻辑——WebSocket本身不区分私聊/群聊，全靠你用clients映射表和targetId字段做定向分发。
客户端发消息时必须带明确的type和targetId
很多初学者卡在“消息发出去但对方收不到”，根本原因是前端没按约定结构发送JSON。服务端只认type（"private"或"group"）和targetId（私聊填对方ID，群聊可填"all"或群组标识），其他字段全被忽略。
-
type === "private"时，targetId必须是服务端已存入clientsMap里的有效用户ID，且clients.get(targetId)?.readyState === WebSocket.OPEN -
type === "group"时，服务端需遍历clients.values()，跳过发送方自身；若用群组ID管理，得额外维护groupMembers: Map<string set>></string> - 前端发送前务必校验
targetId非空、非undefined，否则clients.get(undefined)返回undefined，后续.send()直接报错
clients Map必须实时同步连接状态
WebSocket连接断开时，clients里残留无效引用会导致私聊失败或崩溃。不能只靠connection事件注册，还必须监听close和error事件清理。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 每个
ws实例绑定ws.on("close", () => clients.delete(userId))，userId需提前挂载到ws上（如ws.userId = userId），避免闭包丢失 - 不要用
setInterval轮询心跳——既增加服务器负担，又无法及时感知断连；改用ws.isAlive = true+ping事件回调标记 - 广播在线列表时，只遍历
clients.values()并过滤readyState === WebSocket.OPEN的连接，否则ws.send()会抛WebSocket is not open
群聊广播别直接for...of clients.values()
看似简单粗暴的遍历，在高并发下容易阻塞Event Loop。当在线用户超200人，单次群聊广播可能耗时几十毫秒，导致后续消息积压。
- 用
Array.from(clients.values())先转数组，再用forEach而非for...of，减少迭代器开销 - 对每个
ws调用send()前加if (ws.readyState !== WebSocket.OPEN) continue，避免无意义错误捕获 - 若需支持离线消息，
send()失败后应记录到offlineQueue.set(targetId, [...queue, msg])，而非当场重试
最容易被忽略的是：私聊消息的fromId字段必须由服务端生成并注入，绝不能信任客户端传来的userId。攻击者只要伪造fromId就能冒充他人发消息——这个校验点一旦漏掉，整个私聊功能就失去可信基础。
