Swoole默认不拆包,因TCP是字节流协议,无法自动识别消息边界;必须显式配置open_length_check或open_eof_check才能按长度或结束符拆包。
必须显式配置 open_length_check 或 open_eof_check,否则 Swoole 不会做任何拆包,onReceive 收到的就是原始 TCP 流数据。
TCP 本身是字节流协议,Swoole 不可能猜出你的业务协议格式。它不会自动识别“消息边界”,也不会尝试解析 JSON、XML 或自定义结构。所有拆包逻辑都依赖你明确告诉它:长度在哪、结束符是什么、最大能收多大。
常见错误现象:onReceive 里收到半条消息、两条消息拼在一起、或带乱码的截断数据 —— 这不是 bug,是你没配拆包规则。
open_length_check 且没设 package_eof → 完全无拆包,纯裸流open_eof_check 但数据里混入了 package_eof → 错误切分,后续全乱open_length_check 但 package_length_offset 填错 → 读到错误字节当长度,直接截出垃圾数据open_length_check 配固定包头协议(推荐)这是生产环境最稳的方式,尤其适合二进制或含任意字节的数据。核心是让 Swoole 知道:长度字段在哪、占几个字节、包体从哪开始。
假设协议是「前 4 字节为包体长度(大端 uint32),后面是真实数据」:
$server->set([ 'open_length_check' => true, 'package_length_type' => 'N', // 4 字节无符号大端整数 'package_length_offset' => 0, // 长度值从第 0 字节开始 'package_body_offset' => 4, // 包体从第 4 字节开始 'package_max_length' => 81920, // 防止恶意超长包吃光内存]);
注意点:
package_length_type 必须和 pack() 时用的一致:比如客户端用 pack('n', $len)(2 字节短整型),这里就得填 'n'
package_body_offset 不等于包头长度:如果包头共 16 字节,长度字段在第 12~15 字节,则 package_length_offset 填 12,package_body_offset 填 16
package_max_length 是硬限制,超长包会被直接丢弃,不触发 onReceive
open_eof_check 配文本类简单协议只适用于纯文本、且能确保业务数据中绝不出现在 package_eof 的场景,比如日志推送、命令行交互。
配置示例(以换行符为界):
$server->set([ 'open_eof_check' => true, 'package_eof' => "n", 'open_eof_split' => true, // 让 Swoole 自动剥离 EOF 并分发完整消息]);
关键约束:
send() 必须带上 n,漏了就卡住不触发 onReceive
open_eof_split,onReceive 收到的数据仍含 n,得自己 explode("n", $data) 处理,还要处理跨包换行(比如 "hellonworld" 被拆成 "hellon" 和 "world")TCP 的 open_length_check / open_eof_check 对 UDP 无效。UDP 是报文边界天然存在的协议,每个 onPacket 收到的就是一个独立 UDP 包 —— 但你要自己校验完整性(比如加 CRC、重传逻辑)。
WebSocket 更特殊:onMessage 已经是解帧后的完整文本或二进制帧,Swoole 内部已按 WebSocket 协议完成分帧与重组,**不能也不该再配 open_length_check**。强行配了会冲突甚至崩溃。
最容易被忽略的是:不同传输层(TCP/UDP/WebSocket)的事件回调入口、缓冲区行为、错误恢复策略完全不同。别把 TCP 的配置复制粘贴到 UDP Server 上试。