workerman自动处理websocket分片，onmessage中$data始终为完整消息，无需手动拼接；分片由客户端触发，服务端不主动分片也不提供分片发送api。
WebSocket分片在Workerman里不需手动处理
Workerman 的 Websocket 协议层已按 RFC 6455 自动处理分片（fragmentation）：收到的跨帧消息会被自动拼接，$data 在 onMessage 回调中始终是完整 payload（string 或 binary），无需开发者识别 FIN、opcode 或手动重组。
这是底层 src/Protocols/Websocket.php 的默认行为，不是可开关选项——你写代码时根本感知不到分片存在。
哪些情况会触发分片？Workerman 本身不主动分片
分片由客户端（浏览器或第三方 SDK）控制，Workerman 服务端只负责接收和还原。常见触发场景包括：
- 浏览器发送超长文本（如 >128KB 的 JSON）时，Chrome/Firefox 可能自动分片
- 使用
ws或websocket-client库时设置了maxPayload或启用了fragment选项 - 某些嵌入式设备或旧版 WebSocket 客户端强制分片以适配小缓冲区
Workerman 不会在服务端对 $connection->send() 的数据做分片；它把整个 $data 打包成单个文本/二进制帧发出（除非底层 TCP 层因 MTU 分包，但那是网络层行为，与 WebSocket 分片无关）。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
想发分片消息？Workerman 不提供原生 API
Workerman 没有暴露 sendFragment()、continuationFrame() 这类底层帧操作接口。如果你必须主动发送分片（例如对接某特殊硬件协议），只能绕过 TcpConnection->send()，自己构造 WebSocket 帧并调用 $connection->getSocket()->write() ——但这极易出错，且破坏协议兼容性。
更现实的做法是：
- 确认对方是否真需要分片（多数现代服务不强制）
- 改用支持分片控制的客户端库（如 Node.js 的
ws库）来发起连接 - 在应用层拆分大数据为多个独立
send()调用（带自定义序号/校验），由业务逻辑重组
调试分片问题时重点看哪里？
当遇到“消息截断”“乱码”“只收一半”等现象，90% 不是分片问题，而是：
- 客户端未正确关闭连接，导致后续帧被丢弃
-
onMessage中抛出未捕获异常，中断了帧处理循环 - 客户端发送了二进制帧但服务端误当文本处理（检查
is_string($data)或$data instanceof \Workerman\Protocols\Websocket\Frame） - PHP 内存限制或
worker->count过低，在高并发下丢帧
真要验证分片行为，用 wscat -c ws://localhost:2346 手动发带 FIN=0 的帧几乎不可行——Workerman 不解析原始帧流，只交付还原后的内容。别在这儿浪费时间。
