tcp粘包拆包本质是协议特性所致，因tcp面向字节流、无消息边界；workerman未默认拆包，因其底层socket读取仅返回原始字节流，需用户通过protocolinterface的input等方法自定义协议（如长度头）来准确切分。
Workerman 的 TCP 粘包拆包问题，本质不是 Workerman 的 bug，而是 TCP 协议本身面向流的特性决定的——它不维护消息边界。你不能指望 onMessage 每次回调都对应一个“完整业务包”，除非你主动定义并遵守协议。
为什么 Workerman 默认不帮你拆包
Workerman 的 TcpConnection 在底层调用的是 PHP 的 stream_socket_recvfrom 或 socket_read，它们只管从内核缓冲区里尽可能多地读字节，不关心业务语义。也就是说，$data 可能是半条消息、两条消息拼一起、或带了半个包头的脏数据。
常见错误现象包括：
-
onMessage收到的$data解析失败，JSON decode 报错或 unpack 失败 - 连续发两个短包（如
"login$_"和"move:1,2$_"），服务端一次收到"login$_move:1,2$_" - 发一个大包（比如 2MB 图片 base64），客户端分多次
send()，但服务端onMessage只触发一次，且$data长度不对
必须实现 ProtocolInterface 自定义协议
Workerman 提供了 ProtocolInterface 接口，要求你实现三个方法：input、encode、decode。其中 input 是解决粘包/拆包的核心入口——它在每次从 socket 读到新数据时被调用，返回值决定如何切分缓冲区。
关键逻辑在 input 方法中：
- 返回
0：表示数据不完整，继续攒在连接的缓冲区里等下一次读取 - 返回正整数
n：表示从当前缓冲区头部截取n字节作为一条完整消息，剩余部分留在缓冲区待下次处理 - 返回
false：直接断开该连接（可用于非法包检测）
例如，使用「4 字节长度头 + 原始数据」协议：
public function input($buffer)
{
// 至少要有 4 字节才能读长度
if (strlen($buffer) <h3>三种常用协议方案怎么选</h3><p>实际项目中，选哪种方案取决于你的客户端是否可控、性能敏感度、以及是否已有协议规范：</p>
-
固定长度：适合 IoT 设备或嵌入式场景，简单但浪费带宽。用
FixedLengthFrameDecoder类思路，input直接返回固定值（如128）。缺点是无法传变长内容。 -
分隔符（如
"$_"）：适合纯文本协议（如自定义指令），实现最轻量。但要确保业务数据里绝不会出现该分隔符，否则误切。可用strpos($buffer, "$_")找位置，找不到就返回0。 -
长度头（推荐）：通用性最强，兼容二进制和文本，无字符污染风险。注意大小端一致性（PHP 默认用
N表示 network byte order / big-endian）；客户端 C# 要用BitConverter.GetBytes(len).Reverse().ToArray()或直接IPAddress.HostToNetworkOrder。
容易被忽略的细节
很多人写完 input 就以为万事大吉，但以下几点常导致线上出问题：
-
input方法里不能做耗时操作（如数据库查询、curl），否则阻塞整个进程；它只负责“切包”，解析逻辑放decode或onMessage里 - 每个连接的缓冲区是独立的，但
$buffer是原始字节流，不要用mb_系列函数处理，要用strlen、substr、unpack - 如果客户端发包不守协议（比如长度字段写错），
input返回0会一直等下去，最终触发 Workerman 的max_package_size或超时断连——务必加长度校验和上限保护 - Workerman 的
$connection->send()发送前会自动调用你的encode方法，所以encode必须把长度头打进去，否则客户端收不到合法包
真正麻烦的从来不是写对一个 input，而是让所有接入方（尤其是第三方硬件或旧客户端）严格按协议封包。协议一旦上线，改起来比重构还疼。
