websocket仅负责信令协调，webrtc实现音视频传输；多人房间需按room id分组管理连接，小规模用全网状，超4人应引入sfu；需严格遵循sdp交换顺序并校验ice状态。
WebSocket 本身不直接传输视频，它只负责建立低延迟的双向通信通道。实现多人在线视频房间，需要把 WebSocket 和 WebRTC 结合使用：WebSocket 协调信令（如交换 SDP、ICE 候选），WebRTC 负责实际的音视频传输。
信令服务器用 WebSocket 搭建
所有客户端连接到同一个 WebSocket 服务端，用于传递连接控制信息。服务端不转发媒体流，只中转信令消息。
- 每个房间用唯一 room ID 标识，服务端按 room ID 分组管理 socket 连接
- 用户加入时发送
{ type: 'join', roomId: 'abc123' }，服务端广播给同房间其他人 - 当某人生成 offer，通过 WebSocket 发送给目标用户（或广播给房间内除自己外的所有人）
- ICE 候选（candidate）也通过 WebSocket 逐条发送，不能合并或省略
前端用 WebRTC 建立点对点连接
每个用户既是“发起方”也是“接收方”，需为房间内其他每位成员创建独立的 RTCPeerConnection 实例。
- 本地获取摄像头/麦克风流：
navigator.mediaDevices.getUserMedia({ video: true, audio: true }) - 为每个远端用户 new 一个 peerConnection，配置 STUN/TURN 服务器（至少配 STUN，如
stun:stun.l.google.com:19302） - 监听
ontrack获取远端音视频流，绑定到对应<video></video>元素 - 监听
onicecandidate，把 candidate 发给 WebSocket 服务端，再中转给目标用户
处理多人连接的关键逻辑
三人及以上时，不能只靠全网状（mesh）连接——每人要和其余所有人直连，N 个人就需要 N×(N−1) 条连接，带宽和 CPU 压力陡增。
- 小规模房间（≤4人）可用全网状：A↔B、A↔C、B↔C……每个 peerConnection 独立管理
- 超过 4 人建议引入 SFU（Selective Forwarding Unit），比如用 mediasoup 或 Janus，此时 WebSocket 仍负责信令，但媒体流统一发给 SFU，再由 SFU 转发给订阅者
- 前端需动态管理
RTCPeerConnection生命周期：用户离开时 close 对应连接，避免内存泄漏
常见问题与应对
实际开发中容易卡在连接失败、黑屏、单向音视频等环节，多数源于信令顺序或 ICE 状态未校验。
- 确保 SDP 交换顺序：offer → answer → candidate（offer 方先发 candidate，answer 方收到 offer 后再 setRemoteDescription，再发自己的 candidate）
- 检查 ICE 连接状态：
pc.oniceconnectionstatechange监听'connected'或'completed'再启用 UI 控制 - 禁用浏览器自动播放限制：视频元素加
autoplay muted，有声音时需用户手势触发unmute() - 移动端注意：iOS Safari 对 WebRTC 支持较晚（14.3+），部分 API 如
getDisplayMedia不可用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
