HTML5中无法直接通过WebSocket传输原始语音流实现实时播放，因WebSocket是消息导向协议，不适合连续音频帧流；实时语音通信必须结合WebRTC完成采集、编码、传输与播放，WebSocket仅用于信令控制（如交换SDP和ICE候选）。
HTML5 中无法直接通过 WebSocket 传输原始语音流并实现低延迟实时播放，因为 WebSocket 是消息导向的协议，不适合直接承载连续、高频率的音频帧流；真正的实时语音通信需结合 WebRTC（而非纯 WebSocket）来完成采集、编码、传输与播放。WebSocket 可用于信令控制（如建立连接、交换 SDP 和 ICE 候选），但不负责媒体流本身。
语音采集：用 MediaRecorder 或 WebRTC 获取音频流
浏览器中获取麦克风音频需先请求权限，再创建 MediaStream：
- 调用 navigator.mediaDevices.getUserMedia({ audio: true }) 获取音频流
- 若需录制并分片上传，可用 MediaRecorder（支持 audio/webm、audio/mp4 等格式），但它有启动/停止粒度，不适合毫秒级实时流
- 若追求真正实时（如语音通话），应使用 WebRTC 的 RTCPeerConnection，它能将音频流以编码后（如 Opus）的 RTP 包形式持续发送，延迟可压至 100–300ms
WebSocket 的合理角色：只做信令，不做媒体
WebSocket 在语音场景中应专注协调连接建立过程：
- 客户端 A 生成 offer（SDP），通过 WebSocket 发送给服务端，再转发给客户端 B
- B 回传 answer，双方交换 ICE 候选地址（candidate），全程走 WebSocket 文本消息
- 切勿尝试把 AudioContext 输出的 PCM 数据块通过 WebSocket.send() 频繁发送——易触发背压、丢包、时序错乱，且无拥塞控制和抖动缓冲
服务端不能只靠 WebSocket 中转音频流
若强行用 Node.js + ws 库接收前端发来的音频 ArrayBuffer 并广播，会面临严重问题：
立即学习“前端免费学习笔记（深入）”；
- 无编解码：前端未压缩的 PCM（如 48kHz/16bit 单声道 ≈ 96 KB/s）会迅速打满带宽
- 无同步机制：WebSocket 不保证消息顺序与间隔，播放端难以还原原始节奏
- 无 NAT 穿透：公网用户间无法直连，必须依赖 TURN 服务器中继媒体流（WebRTC 内置支持，WebSocket 没有）
推荐架构：WebRTC + WebSocket（信令）+ SFU/MCU 服务端
生产级实时语音需分层协作：
- 前端：用 RTCPeerConnection 采集、编码、发送音频流；用 WebSocket 连接信令服务器
- 信令服务：基于 ws / Socket.IO，仅处理文本指令（offer/answer/candidate）
- 媒体服务：部署 Mediasoup、Janus 或 LiveKit 等 WebRTC 专用 SFU（Selective Forwarding Unit），高效转发编码后的音频轨道
- 播放端：同样用 RTCPeerConnection 接收并自动解码播放，无需手动处理音频上下文或 BufferSource
