WebSocket仅传输二进制数据，音频播放依赖前后端参数对齐；应直接发送Blob或ArrayBuffer，避免base64；需区分文本与二进制帧；前端用createBuffer解析PCM，服务端须剥离WAV头。
WebSocket 本身不处理音频，它只负责把二进制块按时序、无损地送过去——能不能播、播得对不对，全看前后端是否对齐采样率、声道数、数据类型和帧边界。
ws.send() 直接传 Blob 或 ArrayBuffer 就行，别转 base64
浏览器原生支持 ws.send() 发送 Blob、ArrayBuffer、TypedArray，无需手动转成 base64 字符串再发。转 base64 不仅体积膨胀约 33%，还会增加编解码开销和 GC 压力。
- MediaRecorder 录出的
event.data是Blob，直接ws.send(event.data)即可 - PyAudio 或 AudioRecord 采集的原始 PCM（如
Int16Array），先转成ArrayBuffer再发：ws.send(int16Buffer) - 移动端 Safari 对单次发送的
Blob大小敏感，建议上限设为512 * 1024字节；超限时用blob.slice(0, 512 * 1024)拆分
后端必须区分文本帧和二进制帧，且按序接收
WebSocket 协议不定义业务语义，onmessage 回调收到的数据类型完全取决于前端发什么。混用文本和二进制帧是合法的，但后端必须能识别并路由——否则二进制音频块会被当成字符串解析失败，或被丢弃。
- Node.js（
ws库）中：检查event.isBinary === true才走 Buffer 处理分支；文本帧（如{ "start": true, "sampleRate": 16000 }）用event.toString() - Java（
@ServerEndpoint）中：必须重载两个@OnMessage方法，一个参数为String，一个为ByteBuffer；只写一个会漏掉某类帧 - 关键陷阱：控制帧（如
start、end）必须在音频帧之前/之后发送，且服务端要按收包顺序处理，不能异步乱序拼接
客户端播放 PCM 流不能用 decodeAudioData()
decodeAudioData() 只接受标准容器格式（WAV/MP3/OGG），无法解析裸 PCM 数据流。常见报错 "unknown content type" 就是因为后端发的是 raw Int16Array，前端却拿去喂给 decodeAudioData()。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 正确做法：用
audioContext.createBuffer()手动构造AudioBuffer，填入Float32Array样本（范围 [-1.0, 1.0]） - 服务端需将
Int16转Float32：例如 Python 中用np.frombuffer(data, dtype=np.int16).astype(np.float32) / 32768.0 - 务必对齐参数：采样率（如
16000）、声道数（1或2）、样本长度，三者错一个就破音或静音
连接就绪、采集就绪、鉴权就绪，三者缺一不可
90% 的“发不出去”问题不是代码写错，而是卡在准备环节。WebSocket 连接未 open、MediaRecorder 未 start、token 未送达服务端，都会导致无声或连接中断。
-
ws.readyState必须为WebSocket.OPEN才能发；不要在onmessage里盲目发，应在onopen回调或轮询判断后发送 - MediaRecorder 启动后需监听
onstart和onerror；用户拒授麦克风、系统禁用录音权限、start()调用过早都会让ondataavailable不触发 - 跨域 WebSocket 不带 Cookie，服务端若依赖 Cookie 鉴权会失败；改用
Sec-WebSocket-Protocol: bearer-xxx传 token，或首帧发文本{ "auth": "xxx" }
最易被忽略的一点：WAV 文件有 44 字节头部，但实时流不需要——服务端若把整段 WAV 当作流式数据发，前端会把头部当 PCM 样本解码，结果就是刺耳爆音。流式传输必须剥离头部，只传纯样本数据。
