workerman 4 websocket默认支持二进制消息，但需前端声明子协议（如['binary']）、设置ws.binarytype='arraybuffer'，服务端校验协议并避免utf-8强制转换，自定义帧还需手动处理粘包。

Workerman 4 的 WebSocket 服务默认支持二进制消息，但实际传输中容易因编码方式、客户端兼容性、协议协商或数据处理逻辑出错，导致 onMessage 收不到数据、报错、乱码或连接异常断开。

二进制帧必须明确协商子协议

浏览器或客户端发送二进制数据（如 ArrayBuffer、Blob）前，需在 WebSocket 构造时显式声明子协议，否则 Workerman 可能拒绝或降级为文本处理：

• 前端 JS 正确写法：new WebSocket('wss://example.com/ws', ['binary'])
• 服务端需校验 $connection->getProtocol() 或检查握手头 Sec-WebSocket-Protocol: binary
• 若未协商成功，Workerman 默认按 UTF-8 解析，遇到非合法 UTF-8 字节会抛 Warning 并中断连接

接收端不能直接 echo 或 json_encode 二进制数据

Workerman 的 $connection->send() 对二进制数据有隐式类型判断，但以下操作极易翻车：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• $connection->send($data) 中 $data 是 string 类型且含 \x00\xFF 等字节 —— 只要没被识别为 binary，可能被强制转 UTF-8 导致截断
• 错误示例：json_encode(['frame' => $rawBinary]) → JSON 会把二进制转成 base64 字符串或直接丢弃
• 正确做法：用 pack() / unpack() 显式构造帧；或确保传入的是 strval($binaryString) 且不经过任何字符串函数处理

客户端发 ArrayBuffer，服务端收到却是字符串

这不是 Bug，是浏览器 WebSocket 实现的默认行为：当未设置 binaryType 时，ArrayBuffer 会被自动转为 DOMString（即 UTF-16 编码字符串），再经网络传输后在 Workerman 中表现为损坏的 UTF-8 字符串。

• 前端必须加：ws.binaryType = 'arraybuffer'
• 发送时保持原始类型：ws.send(new Uint8Array([0x01, 0x02, 0x03]).buffer)
• Workerman onMessage 中可通过 is_string($data) && !mb_check_encoding($data, 'UTF-8') 初步判断是否为原始二进制

自定义帧协议时注意粘包与边界识别

WebSocket 协议本身不保证“一帧一消息”，尤其高频发送小二进制包时，Workerman 可能合并多个 send() 成一个 TCP 包送达。若你自定义了帧头（如 4 字节长度 + payload），必须自行拆包：

• 不要依赖 onMessage 触发次数等于发送次数
• 推荐在 onMessage 中缓存未完整帧，并用 while 循环解析缓冲区，直到剩余不足一帧头长度
• 可参考 Workerman 内置 Workerman\Protocols\Http::input() 模式，但需重写 decode() 方法适配你的二进制帧结构