Swoole怎样配置TCP底层拆包规则

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"）
• HTTP、JSON、XML 等含换行的内容，绝对不要用此方式

UDP 和 WebSocket 不走同一套机制

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 上试。