Workerman自定义协议必须实现input、decode、encode方法；input解决粘包/半包，判断数据完整性并返回包长；decode将截取后的完整包解析为业务数据；encode负责序列化发送。
Workerman 接收到的数据包不完整，不是框架 bug，而是 TCP 协议本身的流式特性决定的。你看到的“半包”或“粘包”，本质是操作系统和内核在网络收发时对字节流的自然切分，Workerman 只负责把底层 recv() 拿到的原始字节流交给你，它不会、也不能自动识别业务消息边界。
为什么 onMessage 里收到的 $data 有时短、有时长？
因为 onMessage 触发时机只取决于 socket 缓冲区是否有新数据可读，并不对应你客户端一次 send() 的逻辑包。
- 客户端连续调用两次
send("hi")和send("ok")，服务端可能在一次onMessage中收到"hiok"（粘包） - 客户端发送一个 2KB 的 JSON，内核可能分两次把数据推到缓冲区，
onMessage先触发一次收到 1.2KB，再触发一次收到剩下 0.8KB（半包） - 即使你用
sleep(1)隔开两次 send，也不能保证不粘——TCP 有 Nagle 算法、缓冲区合并等机制
Workerman 自定义协议必须实现 Input 方法
Input 是 Workerman 解决粘包/半包的第一道关卡，它在数据进入 onMessage 前运行，决定“这次要不要继续等”或者“这次该取多少字节”。不实现它，就等于把拆包逻辑全堆在 onMessage 里手动拼接，极易出错。
- 返回
0：表示当前数据不够构成一个完整包，暂存进连接的缓冲区，等下次数据来再一起处理 - 返回正整数（如
4）：表示“从当前缓冲区开头起，取 4 字节作为包头”，后续会自动再调用decode补齐包体 - 返回
false：直接断开该连接（适合校验失败、非法长度等场景）
典型做法是：先读 4 字节头 → 解出 body 长度 → 判断缓冲区总长是否 ≥ 头长 + body 长 → 不够就 return 0，够了就 return 头长 + body 长。
encode/decode 要和 Input 严格配套，不能只做一半
很多人只写 encode 把长度打在前面，却忘了在 Input 里解析它，结果 onMessage 还是收到粘包数据。三者必须闭环：
-
encode：客户端发包前，把pack('N', strlen($body)) . $body拼好再 send -
Input：服务端收到后，检查缓冲区是否 ≥ 4 字节；若够，unpack 得到 body_len；再检查是否 ≥ 4 + body_len；够则返回该总长，否则 return 0 -
decode：Workerman 在确认长度后，自动截取对应字节数传入此方法，你只需返回解包后的业务数据（比如json_decode($data, true)）
注意：decode 的入参是已按 Input 返回值截好的完整包（含头），不是原始缓冲区全量数据。
别在 onMessage 里自己拼接缓冲区
常见错误是声明全局数组 $_CONN_BUF，每次 onMessage 来了就追加 $data，再 while 循环找 \r\n 或解析长度——这极易漏掉边界、重复处理、内存泄漏，且无法应对并发连接。
Workerman 的连接对象（$connection）本身提供 $connection->recv() 和 $connection->send()，但更推荐走协议类路线，因为：
- 协议类由 Workerman 内部管理缓冲区，线程/进程安全
- 避免手动维护连接级状态，减少出错点
- 能复用
Frame、Http等内置协议的设计思路
真正容易被忽略的是：一旦用了自定义协议，所有通信都必须走这个协议封包，包括心跳、错误响应、甚至空包——任何绕过 encode 直接 $connection->send("xxx") 的行为，都会破坏解析逻辑。
