swoole处理tcp粘包主要采用eof分隔和固定包头+包体两种方案；前者通过设置'open_eof_check'和'package_eof'以特殊字符分割数据，适用于文本类简单数据，需确保数据中不包含结束符；后者在数据前添加存有包体长度的头部，通过配置'open_length_check'等参数实现可靠分包，适合二进制或复杂数据传输，稳定性高，为推荐方式。
为什么 swoole_server 的 TCP 连接会粘包
因为 TCP 是流式协议，不保证“一次 send() 对应一次 recv()”。客户端连续两次 write()，服务端可能一次就收到全部数据；也可能第一次只读到一半，第二次才读完。Swoole 默认不做应用层分包，所以 onReceive 回调拿到的 $data 可能是半包、整包或多个包拼在一起。
方案一：用 open_length_check 让 Swoole 自动拆包
这是最常用也最省心的方式，适合包体长度固定或前缀带长度字段的协议（比如前 4 字节是包总长）。
实操要点：
-
open_length_check必须配合package_length_type（如"N"表示 4 字节无符号大端）和package_length_offset（长度字段起始位置）使用 - 如果包头还有魔数（如 0x1234），可加
package_magic_byte和package_magic_byte_offset - 注意
package_max_length要设合理值，否则超长包会被直接丢弃，且不触发onPackage - 开启后，
onReceive不再触发，改用onPackage回调，参数$data就是完整单包
示例配置片段：
$server->set([
'open_length_check' => true,
'package_length_type' => 'N',
'package_length_offset' => 0,
'package_length_size' => 4,
'package_max_length' => 1024 * 1024,
]);
方案二：在 onReceive 里手动缓存 + 判断边界
适用于协议复杂、长度字段需解密/校验，或想完全掌控缓冲逻辑的场景。但容易写错，尤其在连接断开、错误重连时残留数据没清理干净。
关键动作：
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 为每个
$fd维护一个私有缓冲区（如存在$this->recvBuffer[$fd]） - 每次
onReceive把新数据追加进缓冲区，然后 while 循环尝试解析：检查是否有足够字节读取长度字段 → 解出包长 → 检查缓冲区是否够长 → 截出完整包 → 剩余数据留在缓冲区 - 必须在
onClose里清空对应$fd的缓冲区，否则内存泄漏 - 遇到非法包长（如负数、超大值）要主动
close($fd)，防止被攻击
方案三：改用 swoole_websocket_server 或 http 协议
这不是“解决”粘包，而是绕过它——WebSocket 帧自带掩码和长度字段，HTTP 有 Content-Length 或 chunked 编码，Swoole 底层已帮你处理好分包。
适用前提：
- 客户端可控（比如你写的 App 或 Web 前端），能按 WebSocket 协议通信
- 不需要裸 TCP 的低延迟或自定义二进制格式
- 业务本质是请求-响应模型，而非长连接持续推送
注意：swoole_websocket_server 仍基于 TCP，只是协议层做了封装；它不会自动帮你处理自定义二进制子协议，除非你在 onMessage 里再做一次解析。
方案四：用 swoole_http_client 或 swoole_redis 等协程客户端时怎么防粘包
这类客户端本身不暴露原始 TCP 流，它们内部已按协议解析完毕。但如果你用 swoole_coroutine_socket 手动 recv()，粘包问题照旧存在。
重点提醒：
-
swoole_coroutine_socket::recv()默认是阻塞读，不等于“读完一整包”，它只按你给的 buffer 长度读最多那么多字节 - 别依赖
recv(8192)就认为能读完一个逻辑包——得自己实现类似方案二的缓冲逻辑 - 如果服务端是标准 Redis 协议，优先用
swoole_redis，它已内置 RESP 解析；同理，HTTP 用swoole_http_client，别手撸 socket
真正麻烦的不是选哪种方案，而是协议设计阶段没定好包边界规则。很多线上问题，根源是客户端发包时长度字段填错了，或者服务端配置的 package_length_offset 和实际协议对不上——这种错不会报异常，只会静默丢包或解析错乱。
