必须共存：WebSocket负责信令（如SDP交换、状态同步），WebRTC负责低延迟音视频传输；WebSocket基于TCP导致音频延迟高、无内置音视频处理，WebRTC的RTCDataChannel不可靠且无中心化控制，无法替代WebSocket传消息。
实时音视频必须用 WebRTC，即时通讯（文字/状态/控制指令）必须用 WebSocket。两者不是“二选一”，而是分工明确、必须共存的组合。
为什么不能只用 WebSocket 传音频？
WebSocket 基于 TCP，所有数据包必须按序、不丢地送达。网络稍有抖动，就会触发重传，导致音频延迟飙升到 300ms 以上，甚至卡顿断连。语音通话中“等重传”比“丢几个包”更破坏体验——人耳对延迟敏感，对轻微杂音容忍度反而更高。
常见错误现象：
- 本地录音正常，对方听到的声音有明显回声或延迟感
- 弱网下音频频繁卡顿，但 WebSocket 连接本身显示“在线”
- 用
WebSocket.send(audioChunk)传输 Opus 编码数据时，端到端延迟始终 >250ms
关键限制：
-
WebSocket不提供内置的 JitterBuffer、FEC、NACK 或带宽自适应逻辑 - 无法直接接入浏览器原生的回声消除（
echoCancellation: true）和噪声抑制模块 - 音频流需手动分片、标记时间戳、处理乱序重组——这些本该由
RTCPeerConnection自动完成
为什么不能只用 WebRTC 传聊天消息？
WebRTC 的 RTCDataChannel 确实能传文本，但它不是为高可靠、低开销的信令设计的。一旦 P2P 连接因 NAT/防火墙失败，整个消息通道就断了；而 WebSocket 只要服务器可达，就能持续收发控制指令。
典型踩坑点：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 用户 A 和 B 在不同内网，
RTCPeerConnection始终无法建立，但聊天消息仍需送达（比如“用户已离开房间”） -
RTCDataChannel设为reliable: false后，消息丢失无通知；设为true又引入 TCP 式延迟 - 服务端无法主动向某个用户推送消息（例如踢出指令），因为
WebRTC没有中心化控制面
实际项目中，WebSocket 承担的角色包括：
- 房间创建与成员同步（
joinRoom,userLeft） - SDP offer/answer 和 ICE candidate 的中转（没有它，
WebRTC根本连不起来） - ASR 识别结果返回、TTS 播放状态回调等异步事件
怎么搭起这个双通道协作结构？
核心原则：信令走 WebSocket，媒体走 WebRTC，两者生命周期解耦。连接建立顺序不能错。
正确初始化步骤：
- 页面加载后立即新建
WebSocket实例（如const ws = new WebSocket("wss://signaling.example.com")），并监听open事件 - 等
ws.readyState === WebSocket.OPEN后，再调用getUserMedia和初始化RTCPeerConnection -
RTCPeerConnection的iceCandidate事件一触发，立刻通过ws.send(JSON.stringify({type: "candidate", candidate: event.candidate}))中转 - 收到对方的 SDP 或 candidate 后，必须先检查
pc.remoteDescription是否已设置，再调用setRemoteDescription，否则报错InvalidStateError
性能提示：
- WebSocket 心跳建议设为 30s（
ping帧），避免被代理断连 - WebRTC 的
iceServers至少配一个公共 STUN（如"stun:stun.l.google.com:19302"），TURN 服务器留作兜底 - Opus 音频务必启用
useinbandfec: 1和minptime: 10，这对弱网抗丢包效果显著
最容易被忽略的是信令与媒体的状态同步：WebSocket 断开时，WebRTC 连接未必立刻失效，但后续新加入用户将无法获取你的 SDP；反过来，WebRTC 媒体流中断（如用户禁麦）也不应自动关闭 WebSocket。两者的错误恢复策略必须独立设计，不能互相绑架。
