websocket在音视频连麦中仅负责信令交换，如sdp协商、ice候选者传递、房间管理等，不传输音视频流；消息需统一json格式带type字段，严格匹配webrtc生命周期处理状态与资源释放。
WebSocket 在音视频连麦或直播间中主要承担信令交换（signaling）任务，即在客户端之间传递 SDP 协商信息、ICE 候选者、加入/离开房间、用户状态等控制指令，它本身不传输音视频流——媒体流走的是 WebRTC 的 P2P 或 SFU/MCU 架构。
信令流程的核心职责
WebSocket 不参与编解码、不转发音视频帧，只做“传话人”。典型信令交互包括：
- 用户 A 发起连麦：发送
offerSDP 到服务端，服务端广播给房间内其他用户（如用户 B） - 用户 B 收到后生成
answer，通过 WebSocket 回传给 A - 双方各自收集 ICE 候选者（candidate），逐条通过 WebSocket 发送给对方（注意：不是打包成数组一次性发）
- 处理房间管理事件：如
{"type":"join","roomId":"live_123","userId":"u456"}
WebSocket 连接与消息结构设计
建议采用统一 JSON 格式，带 type 字段区分消息类型，便于前端路由和后端分发：
- 连接建立后立即发送
{"type":"auth","token":"xxx"}完成鉴权 - SDP 消息带 roomId 和 from/to 字段：
{"type":"sdp","roomId":"live_123","from":"u456","to":"u789","sdp":"v=0\r\no=- ...","role":"offer"} - ICE 候选者单独发送：
{"type":"candidate","roomId":"live_123","from":"u456","candidate":"candidate:abc...","sdpMid":"0","sdpMLineIndex":0} - 避免在单条消息中塞多个 candidate，防止丢包导致部分候选者丢失
关键健壮性处理
真实场景中网络波动常见，需主动应对：
- WebSocket 断连时，WebRTC 连接不会自动断开，但信令中断会导致无法更新 candidate 或处理新用户加入；应监听
onclose并触发重连 + 状态同步（如重新拉取当前房间成员列表） - 服务端需维护每个房间的在线用户映射（如 Map
>），确保 offer/answer/candidate 精准路由，不广播给无关用户 - 前端对重复 candidate、过期 SDP（比如 answer 对应已失效的 offer）做基础校验，避免调用
setRemoteDescription失败 - 大直播间慎用全量广播：百人以上房间，offer/answer 只需点对点；用 Redis Pub/Sub 或消息队列分流信令压力
与 WebRTC 实例的协作时机
信令逻辑必须严格对齐 WebRTC 生命周期：
- 创建
RTCPeerConnection后，立即监听icecandidate事件，每收到一个 candidate 就发一条 WebSocket 消息 - 收到远程
offer后，先setRemoteDescription，再createAnswer→setLocalDescription→ 发送 answer - 收到远程
answer或candidate时，检查peerConnection.signalingState === "have-remote-offer"等状态，避免乱序调用 - 用户离开房间时，主动关闭 WebSocket 并调用
peerConnection.close()，清理资源
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
