websocket不能直接传输语音流，因其基于tcp协议存在队头阻塞问题，导致延迟高、卡顿且不可扩展；它仅适合信令控制，音频流传输必须依赖webrtc。
WebSocket 本身不能实现语音通话，它只负责传递信令；真正传输音频流的是 WebRTC。强行用 WebSocket 传原始音频 PCM 数据会卡顿、延迟高、不可扩展——这是新手最常踩的坑。
为什么不能直接用 WebSocket 传语音流
WebSocket 是基于 TCP 的全双工文本/二进制通道，天然有队头阻塞（head-of-line blocking）问题。语音对实时性极其敏感，要求端到端延迟
常见错误现象：audioContext.createBufferSource() 播放时断续、延迟飙升、CPU 占用持续 90%+，本质是把实时流当文件在 WebSocket 上 chunk-by-chunk 发送。
- WebSocket 适合传：SDP offer/answer、ICE candidate、用户状态（如“正在说话”）、控制指令（如 mute/unmute）
- WebRTC 适合传：加密后的音频帧、视频帧、数据通道消息
- 两者分工必须明确，混用等于放弃 WebRTC 的全部优势
RTCPeerConnection 初始化必须配 STUN/TURN
不配置 ICE 服务器，RTCPeerConnection 在多数局域网或 NAT 后根本连不上。仅靠 stun:stun.l.google.com:19302 能解决约 85% 的直连场景，但企业内网、4G/5G 移动网络、对称型 NAT 下必须依赖 TURN 中继。
实操建议：
- 开发阶段先用免费 STUN：
{ urls: 'stun:stun.l.google.com:19302' } - 测试阶段加一个公共 TURN（如 Coturn 部署实例），配置格式为：
{ urls: 'turn:your-turn-server.com:3478', username: 'user', credential: 'pass' } - 生产环境务必自建 TURN 服务，避免音频流经第三方服务器泄露隐私
- 检查 ICE 连接状态：
peerConnection.iceConnectionState必须变成'connected'或'completed'才算真正通了
getUserMedia 权限失败的三个典型原因
navigator.mediaDevices.getUserMedia({ audio: true }) 报错不是“没麦克风”，而是权限链断裂。浏览器只在安全上下文（HTTPS 或 localhost）下允许获取媒体设备，且必须由用户手势（click/tap）触发。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
容易被忽略的细节：
- HTTP 站点（非 HTTPS、非 localhost）直接拒绝，控制台报
NotAllowedError: Permission denied - 自动播放策略阻止：Chrome 会静音无用户交互的音频流，即使拿到
MediaStream，remoteStream.getAudioTracks()可能为空 - 移动端 Safari 对
audio: true单独请求更严格，必须同时带video: false显式声明，否则返回空流 - 调试技巧：在控制台手动执行
navigator.mediaDevices.enumerateDevices()，确认kind: 'audioinput'设备存在且label非空
WebSocket 信令必须处理连接中断与重连
信令断开不等于通话断开，但会导致后续 ICE 候选丢失、新 offer/answer 无法送达，最终表现为“对方听不到你，你也听不到对方”，而 RTCPeerConnection 状态仍显示 'connected' —— 这是最难排查的问题之一。
关键动作：
- WebSocket
onclose触发时，立即调用peerConnection.close()并清空本地流，防止资源泄漏 - 重连成功后，不能直接复用旧的
RTCPeerConnection，必须新建实例并重新走 offer/answer 流程 - 发送信令前务必检查
ws.readyState === WebSocket.OPEN，否则消息静默丢失 - 服务端需支持信令消息的“离线缓存”：比如用户 A 发 offer 时 B 的 WebSocket 断开，B 重连后应主动拉取未读信令
真正的难点不在代码行数，而在于理解哪部分该由 WebSocket 承担、哪部分必须交给 WebRTC 处理。很多“通话不通”的问题，其实只是信令没送到位，或者 ICE 还在收集却误以为已连通。
