text协议基于TCP、以换行符分隔消息，自动缓冲切分并触发onMessage；但要求数据不含\n，否则会错误截断，不适用于二进制或含换行的JSON等场景。

TCP协议本身不定义消息边界，text协议是基于TCP实现的、带换行符分隔的应用层协议。 你不能直接“用TCP协议收发JSON”，而必须自己处理粘包/半包；text协议则帮你自动按 \n 切分，省去手动解析逻辑——但前提是你的数据天然不含 \n。

为什么直接用tcp://会收到乱七八糟的字节流

TCP是字节流协议，onMessage 回调拿到的 $data 可能是：半条JSON、两条HTTP请求拼在一起、或者一个大文件被拆成三段发来。WorkerMan不会替你判断哪部分是一次完整业务消息。

• 没有内置解码逻辑，decode 方法默认返回原样，你得自己写
• 如果客户端发 {"a":1}\n{"b":2}\n，TCP模式下你可能一次收到全部，也可能只收到 {"a":1}\n{"b"
• 调试时用 telnet 发数据容易卡住，因为没换行就等不到 onMessage 触发

text://协议实际做了什么

它在TCP基础上加了一层简单规则：把每个 \n（含 \r\n）当作消息结束符，自动缓冲、切分、触发 onMessage。本质是封装了基础的行协议（Line-based Protocol）。

• 服务端初始化写 new Worker('text://0.0.0.0:2346')，不用改业务代码
• 客户端必须每条消息结尾加 \n，否则服务端一直等下去（超时由底层 TCP keepalive 控制）
• 发送 hello\nworld\n，onMessage 会分别触发两次，$data 是 "hello" 和 "world"
• 不支持二进制数据——只要消息体里有 \n，就会被错误截断

什么时候必须放弃text://，改用frame://或自定义decode

当你传输的数据无法保证不含 \n，或者需要严格帧控制（比如指令+校验和必须原子处理），text协议就不可靠了。

• 传感器上报原始 bin 数据，里面含 \x0a 字节 → 用 frame://，头部存长度
• 用户可能粘贴带换行的JSON或日志 → text协议会错切成多条，必须用 frame:// 或自定义 decode()
• 要兼容 telnet 调试但又需传二进制 → 改用 base64 编码后走 text，但增加体积和CPU开销
• 性能敏感场景（如万级连接高频小包）→ text协议每次都要扫描 \n，frame:// 直接读头+memcpy 更快

真正容易被忽略的是：text协议的“简单”只对纯文本友好；一旦业务数据开始出现换行、空格、不可见字符，问题就从“好不好用”变成“会不会丢数据”。别等上线后查粘包才想起看协议选型。