WebSocket不处理语音，仅负责信令协调；实时语音轮转需WebRTC传输音频，WebSocket传递控制指令、协商连接及同步麦克风状态。
WebSocket 本身不处理语音，它只负责低延迟、双向的文本或二进制消息通信。网页版狼人杀的“实时语音轮转”（如法官指定某玩家发言、禁言、切麦、按顺序传递话筒）需要 WebSocket 配合 WebRTC 实现，不能单靠 WebSocket 完成语音传输。
语音功能必须用 WebRTC，WebSocket 只做信令协调
浏览器无法通过 WebSocket 直接发送原始音频流——带宽、编解码、回声消除、设备控制等都由 WebRTC 原生支持。WebSocket 的真实角色是：
- 传递用户加入/退出、身份分配（狼人/平民/预言家等）、游戏阶段切换（天黑/天亮）等控制指令
- 在玩家间协商 WebRTC 连接：交换 SDP Offer/Answer、ICE Candidate
- 实现“语音轮转”逻辑：例如法官发送
{"type":"grant_mic","playerId":"p3"}，前端收到后调用localStream.getAudioTracks()[0].enabled = true - 同步静音状态、举手请求、强制切麦等操作，确保只有当前被授权者能上麦
语音轮转的核心流程设计
以“白天发言环节按顺序轮转话筒”为例，服务端需维护一个发言队列和当前持有者。关键动作包括：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 法官点击“开始发言”，服务端广播
{"phase":"day_speech","order":["p1","p5","p2"],"current":"p1"} - 玩家 p1 收到后启用本地麦克风，其他人的音频轨道设为
enabled = false - p1 发言结束点击“结束”，前端发
{"type":"next_mic"}给服务端 - 服务端更新
current为下一位，广播新状态；对应玩家自动开麦，其余保持静音 - 支持插队（如预言家查验后立即发言）：法官发
{"type":"assign_mic","target":"p4"}，跳过队列直接授权
避免常见坑：权限、兼容性与体验细节
真实落地时容易忽略但影响极大的点：
立即学习“前端免费学习笔记（深入）”；
-
麦克风权限必须在用户手势触发下申请：不能页面加载就
navigator.mediaDevices.getUserMedia({audio:true})，需绑定到“加入房间”或“开启话筒”按钮 - WebRTC 连接不是全网状：10 人房间若每人直连其他 9 人，带宽和 CPU 压力巨大。推荐使用 SFU（如 Mediasoup、LiveKit）做中转，仅转发当前发言者音频
-
静音 ≠ 关闭轨道：调用
track.enabled = false仍保持连接、低功耗；而track.stop()会彻底释放设备，再次启用需重新申请权限 - 网络抖动下的轮转容错：若 p1 未发出 “next_mic”，服务端可设 60 秒超时自动推进，并广播提示“超时，轮到 p5”
简化起步建议：先做可控最小原型
不必一上来就支持 12 人全功能。推荐分步验证：
- 2 人 + 1 法官：用 WebSocket 同步“谁正在说话”，双方用 WebRTC 点对点通话，法官用按钮控制授权
- 接入 SFU：将点对点改为经服务器中转，验证单路音频广播的延迟（理想值
- 加入发言计时器：前端倒计时 + 到时自动触发
next_mic，避免人为卡顿 - 最后叠加角色行为约束：例如狼人夜间不能发言、预言家查验后获得额外发言权等，均由 WebSocket 指令驱动前端状态
