必须设binaryType='arraybuffer'，否则浏览器强制UTF-8解码PCM等二进制数据，导致乱码或DOMException；需在onopen后、onmessage前设置，并用Int16Array解析ArrayBuffer播放。
WebSocket二进制流必须设binaryType，否则收不到原始音频
浏览器默认把WebSocket收到的二进制数据转成string，一旦你传的是PCM或WAV chunk，就会被强制UTF-8解码——轻则乱码，重则直接抛DOMException: Failed to execute 'decode' on 'TextDecoder'。这不是连接问题，是类型错配。
必须在连接建立后、监听message事件前，显式设置：
const socket = new WebSocket('ws://localhost:8000/audio');
socket.binaryType = 'arraybuffer'; // 关键！不能是'blob'或未设置
socket.onmessage = (e) => {
if (e.data instanceof ArrayBuffer) {
// ✅ 正确拿到原始字节
const pcm = new Int16Array(e.data);
playAudio(pcm);
}
};-
binaryType = 'arraybuffer'：适合高频读写、需逐字节操作（如PCM重采样、VAD检测） -
binaryType = 'blob'：适合大块数据暂存（如整段WAV写入文件），但每次blob.arrayBuffer()会触发内存拷贝，实时场景慎用 - 不设或设为
'blob'时，e.data是Blob对象，new Int16Array(e.data)会直接报错
前端播放PCM流要用AudioContext + ScriptProcessorNode或AudioWorklet
直接用<audio>标签无法播放“持续涌来的PCM裸数据”，它只认完整URL或Blob URL。实时流必须走Web Audio API手动喂数据。
推荐路径（兼容性与性能兼顾）：
const audioCtx = new (window.AudioContext || window.webkitAudioContext)();
const sampleRate = 16000; // 必须和后端一致！
let bufferLength = 512;
<p>function playAudio(pcmInt16) {
const float32 = new Float32Array(pcmInt16.length);
for (let i = 0; i < pcmInt16.length; i++) {
float32[i] = pcmInt16[i] / 32768; // int16 → [-1, 1]
}</p><p>const source = audioCtx.createBufferSource();
const buffer = audioCtx.createBuffer(1, float32.length, sampleRate);
buffer.copyToChannel(float32, 0);
source.buffer = buffer;
source.connect(audioCtx.destination);
source.start();
}- 采样率错配（比如后端发16kHz PCM，前端按44.1kHz解析）会导致音调失真或爆音
- 频繁创建
BufferSource有开销；高帧率场景（如每20ms一帧）建议复用AudioWorklet做环形缓冲 - 移动端Safari对
ScriptProcessorNode已弃用，必须用AudioWorklet，且需提前加载模块：audioCtx.audioWorklet.addModule('processor.js')
后端推送节奏失控，前端音频会卡顿或跳帧
WebSocket本身不保证发送频率。如果后端一股脑send()大量小chunk（比如每5ms发64字节），TCP包可能被合并或延迟，前端收到的间隔就不是均匀的——AudioContext缓冲区空了就静音，满了就丢帧。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
实测稳定方案（以Python Flask + WebSocket为例）：
# 后端控制节奏：固定chunk大小 + 显式sleep import time SAMPLE_RATE = 16000 CHUNK_MS = 20 # 每次推20ms数据 CHUNK_SIZE = int(SAMPLE_RATE * CHUNK_MS / 1000) * 2 # int16 → 2字节/样本 <p>for pcm_chunk in audio_stream: ws.send(pcm_chunk.tobytes()) # 确保是bytes，非numpy array time.sleep(CHUNK_MS / 1000) # 强制节奏，避免突发
- 前端可加简单抖动缓冲：累积3–5帧再开始播放，平滑网络波动
- 不要依赖
time.sleep()精确到毫秒级，ESP32或低配服务器可能不准；优先用硬件定时器或RTOS tick - Spring Boot等Java后端注意
Session.getBasicRemote().sendBinary()是阻塞调用，高并发下需异步线程池包装
Chrome调试时看不到二进制帧？打开chrome://inspect里的WebSocket面板
开发者工具Network标签页默认不显示WebSocket二进制帧内容，容易误判“没收到数据”。实际数据可能早已抵达，只是没被正确解析。
正确调试路径：
- 打开
chrome://inspect→ 找到你的页面 → 点Configure...→ 勾选Discover network targets - 在DevTools中切换到
Application→WebSocket侧边栏 → 选择连接 → 点击Frames标签 - 这里能看到每帧的
Type（binary/text）、Size、Time，双击可查看十六进制原始字节
常见陷阱：看到binary帧但长度为0，说明后端send(b'')或前端binaryType未生效；看到text帧却含乱码，基本确定binaryType漏设。
真正难的不是连上WebSocket，而是让字节从麦克风出来，经网络不丢不粘不乱序，最后在扬声器里还原成连续的声音——每个环节的缓冲策略、时序假设、错误恢复，都得亲手掐着毫秒调。
