该用 tcp:// 协议时是需裸 tcp 控制权，如对接 redis/mqtt/自定义二进制协议；该用 frame:// 时是需自动粘包处理且传输二进制帧（如图片、msgpack），但客户端必须严格按大端 4 字节长度头格式发送。
什么时候该用 tcp:// 协议
直接用 tcp:// 就是裸 TCP，Workerman 不做任何分包、粘包处理，所有数据以原始字节流形式到达 onMessage 回调。适合你已经自己实现了完整协议栈（比如对接 Redis、MQTT、自定义二进制协议），或者明确要绕过框架的协议层干预。
常见错误现象：onMessage 收到的数据长度不稳定、偶尔合并多个请求、或被截断；调试时发现 $data 里混着两段 JSON 或半截包头。
使用场景包括：
- 对接已有 TCP 服务（如私有硬件设备、旧系统接口）
- 协议逻辑复杂，需完全控制
read/write行为（比如带状态机的交互流程） - 性能敏感，想避免框架额外的 decode/encode 开销
什么时候该用 frame:// 协议
frame:// 是 Workerman 内置的轻量二进制协议，底层用「4 字节大端网络序长度头 + 原始 payload」封装，自动处理粘包、分包，onMessage 拿到的就是完整 payload（不含长度头）。
它不解析内容，也不校验结构，只负责把“一帧”干净地交给你——所以适合传输图片、音频片段、序列化后的数组（如 msgpack、igbinary）、或你自己定义的二进制结构体。
注意点：
- 客户端必须按 frame 格式发数据（先写 4 字节长度，再写内容），否则服务端会卡在
input阶段一直等满长度 - 单帧最大支持约 4GB（
0xFFFFFFFF），但实际建议控制在几 MB 内，避免内存暴涨 - 不兼容文本类协议（比如不能直接发 JSON 字符串，除非你手动加长度头）
tcp:// 和 frame:// 的关键参数差异
两者监听写法看起来一样：new Worker('tcp://0.0.0.0:1234') vs new Worker('frame://0.0.0.0:1234')，但背后行为完全不同：
-
tcp://：没有默认input/decode，$connection->send($data)发什么就传什么 -
frame://：强制走Frame::input()（读前 4 字节取长度）、Frame::decode()（剔除头）、Frame::encode()（自动加头） - 如果你给
frame://的onMessage返回值是字符串，send()会自动加头；但若返回的是已含长度头的二进制，就会变成双倍头——这是最容易踩的坑
选错的典型后果和排查线索
选 tcp:// 却没处理粘包 → 客户端发 3 条消息，服务端 onMessage 只触发 1 次，且 $data 是拼接体；Wireshark 抓包能看到连续无分隔的 TCP segment。
选 frame:// 但客户端没加长度头 → 连接不报错，但 onMessage 死活不触发，Worker::$logFile 里反复出现 waiting for more data... 类似提示。
真正复杂的点不在协议本身，而在于客户端是否与服务端对齐了帧格式。哪怕只是长度头用小端而非大端，整个链路就静默失败——这种问题不会抛异常，只会“没反应”。
