Workerman 不支持直接传输语音流，因其无音频编解码、缓冲控制及 WebRTC 信令能力；实时语音对讲必须用 WebRTC 实现媒体直连，Workerman 仅作 SDP 和 ICE 信令中转。
Workerman 本身不支持直接传输语音流（如 PCM、Opus、AAC），它没有内置的音频编解码、缓冲控制或 WebRTC 信令能力。想用 Workerman 做客服与用户的「实时语音对讲」，必须绕过它的 WebSocket 连接层做协议适配，且需额外引入 WebRTC 或 RTMP/RTSP 等媒体传输栈——纯靠 workerman/workerman + onMessage 转发二进制音频帧，会立刻卡死、丢包、不同步。
为什么不能直接用 WebSocket 转发原始语音数据
WebSocket 是文本/二进制通用通道，但 Workerman 的 onMessage 默认把收到的 $data 当作完整帧处理；而语音流是连续小包（如每 20ms 一帧 Opus），前端通过 MediaRecorder 或 WebRTC RTCPeerConnection 产出的数据块大小不固定、无边界标记。Workerman 不做粘包/拆包处理，直接 $connection->send($data) 会导致：
- 前端
onmessage收到的event.data可能是半帧或拼接帧，解码失败 - 高并发下 TCP 缓冲区堆积，延迟飙升（实测 >800ms）
- Workerman 进程被大体积
BinaryData阻塞，影响其他连接心跳
可行路径：WebRTC + Workerman 仅作信令中转
真正低延迟语音对讲必须走 WebRTC，Workerman 只负责交换 SDP 和 ICE candidate，不做媒体流穿透。这是目前唯一稳定落地的方式：
- 前端用
RTCPeerConnection建立 P2P 音频通道，客服端和用户端直连 - Workerman 启一个
websocket://:2346服务，只处理offer/answer/ice-candidate三类 JSON 消息 - 连接建立后，所有音频数据走 UDP，Workerman 进程完全不参与传输
- 示例消息结构：
{"type":"offer","from":"user_123","to":"kf_456","sdp":"v=0..."}
如果非要 Workerman 承载音频流（不推荐）
仅限内网、极低并发、可容忍卡顿的测试场景，必须手动加流控和帧头：
- 前端用
AudioContext+ScriptProcessorNode（已废弃，改用AudioWorklet）切分 20ms PCM，每帧前加 4 字节长度头（pack('N', $len)） - Workerman 端用
$connection->getRemoteIp().':'.$connection->getRemotePort()做会话键，缓存最近 3 秒音频帧数组，避免直接send()堵塞 - 客服端接收时，必须按长度头逐帧剥离，再喂给
AudioContext.decodeAudioData()；否则播放错乱 - 禁用 Workerman 的
heartbeat_idle_time，否则语音流静音期会被误断连
关键避坑点
很多人试图把 MediaStream 的 blob 或 arraybuffer 直接 send()，结果发现：
-
new WebSocket('ws://...')连上后，ws.send(arraybuffer)发送成功，但 WorkermanonMessage收到的是空或截断——因为没设$connection->protocol = 'websocket';，或没在 Worker 构造时指定websocket://协议 - 用
file_get_contents('php://input')强读原始 body？Workerman 不走 PHP-FPM，该方式根本无效 - 以为加
$ws_worker->reloadable = false;就能扛住音频流？只是防止热更，不解决 IO 阻塞
真正的瓶颈不在协议，而在 PHP 语言层无法高效处理毫秒级音频调度——这事该交给浏览器或 C++ 写的媒体服务器（如 SRS、Mediasoup），Workerman 最好只干它擅长的事：轻量信令、状态同步、离线消息兜底。
