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()方法适配你的二进制帧结构
