WebSocket不能直接传语音，只负责同步麦克风开关状态；它仅传递控制指令（如grant_mic、revoke_mic），由前端本地执行enabled=true/false，WebRTC或I2S负责实际音频传输。
WebSocket 不能直接传语音，只负责同步麦克风开关状态
很多人一上来就用 socket.send(audioData) 尝试把音频流塞进 WebSocket，结果卡顿、丢帧、内存暴涨——这是根本性误解。WebSocket 是文本/二进制消息通道，不是音频管道。它该干的事只有一件：**在房间内精准广播“谁正在说话”“谁被禁言”“谁刚举手”这类控制指令**。
真正传语音的必须是 WebRTC（浏览器）或 I2S+WebSocket 组合（ESP32），而 WebSocket 的唯一职责是让所有客户端对“当前话筒归属”达成瞬时共识。
- 前端收到
{"type":"grant_mic","playerId":"p7"}后，调用localStream.getAudioTracks()[0].enabled = true - 法官点击“切麦”，服务端不操作音频，只广播
{"type":"revoke_mic","from":"p7","to":"p2"} - 所有客户端监听该事件，各自本地执行静音/解禁逻辑，无需等待服务器返回确认
- 若某客户端没收到消息（如短暂断连），靠服务端重发最近 3 条状态变更 + 前端定时轮询
/api/room/{id}/mic-state补全
如何避免“多人同时上麦”的竞态问题
两个玩家几乎同时点击麦克风按钮，前端都发了 {"action":"request_mic"}，后端若简单接受第一个请求，第二个会静音失败但 UI 无反馈——用户以为功能坏了。
必须引入原子性状态机，服务端用单线程或带锁机制处理每个房间的麦克风调度：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 每个房间维护一个
currentMicHolder: string | null和pendingRequests: string[]队列 - 收到
request_mic时，仅当currentMicHolder === null且队列为空，才立即授麦；否则入队 - 授麦后触发
mic_granted事件；释放麦（主动关闭或超时）后自动从队列取下一个 - 前端按钮需置灰 + 显示“排队中（第2位）”，避免用户狂点
浏览器端麦克风状态与 WebSocket 消息的绑定时机
用户点“开麦”按钮，不能等 WebSocket 返回成功再启用音频轨道——网络延迟会导致明显滞后感。正确做法是 UI 立即响应 + 异步校验：
- 点击瞬间：更新本地 UI 状态（按钮变亮）、调用
localStream.getAudioTracks()[0].enabled = true - 同时发送
{"action":"request_mic","timestamp":Date.now()}到服务端 - 服务端校验通过后广播
{"type":"mic_granted","playerId":"p5","seq":123} - 前端收到后比对
seq，若与自己发出的请求匹配，则保持开启；若不匹配（比如被更高优先级中断），立刻执行.enabled = false - 若 1.5 秒未收到广播，触发降级：UI 显示“授权失败”，自动关闭本地轨道并提示重试
ESP32 等嵌入式设备怎么用 WebSocket 同步语音状态
ESP32 没有 WebRTC，但它能用 I2S 采集 PCM 音频，再通过 WebSocket 把“正在录音”“识别中”“播放回复”这些状态推给手机 App 或网页后台。关键在于状态帧必须轻量、可丢弃、带时间戳：
- 状态消息结构固定为
{"s":"rec","t":1747954812345,"v":1}（s=state,t=毫秒时间戳,v=值），总长不超过 32 字节 - 使用
esp_websocket_client的websocket_client_send_text()发送，禁用 Nagle 算法（TCP_NODELAY）减少延迟 - 前端不依赖该状态做音频播放控制，只用于 UI 反馈（如小红点闪烁）；真实音频流走独立 UDP 通道或 RTSP
- ESP32 断连重连后，先发一条
{"s":"init","v":{...}}包含当前硬件状态（电池、麦克风是否插拔），避免 App 显示错误状态
实际最难的不是发消息，而是让所有终端对“此刻谁有麦”达成零误差共识——这要求服务端状态机绝对可靠，前端容错逻辑必须覆盖断连、乱序、重复等所有网络异常。别在 WebSocket 上堆音频数据，它天生不是干这个的。
