pipe快因内核字节流通道、无序列化开销、纯内存拷贝，但仅限父子进程；message_queue灵活因支持任意进程通信、消息持久化及类型过滤，但性能较低。
pipe通信为什么快但受限于父子进程关系
pipe 是内核提供的字节流通道，无序列化开销、无消息边界管理、不经过内核 IPC 子系统（如 msgget），纯内存拷贝，所以延迟极低。但它只能在有亲缘关系的进程间使用，比如 swoole_process 创建的子进程与父进程之间。
常见错误是试图用 pipe 让两个独立启动的 Worker 进程通信——会失败，因为没 fork 关系，read() 阻塞或直接返回 0。
另外 pipe 默认是 SOCK_STREAM 类型（流式），数据无边界；若需按包读取，得自己加协议头或改用 $create_pipe = 2 启用 SOCK_DGRAM（注意：仅限 1.7.22+，且仍不保证可靠投递）。
message\_queue 为什么慢一点但更灵活
SwooleMsgQueue 底层调用的是 System V 或 POSIX 消息队列，每次 push() / pop() 都要进内核态、查队列 ID、加锁、拷贝消息体、维护链表——多几轮上下文切换和内存分配，吞吐量天然低于 pipe。
但它支持任意进程通信（只要知道 key 或 name），进程退出后消息不丢失（除非显式 ftok + msgctl(..., IPC_RMID)），还能按 msg_type 过滤读取，适合任务分发场景。
注意：PHP 层的 SwooleMsgQueue 构造时传的整数 ID（如 1234）必须全局唯一，否则不同进程可能误连到同一队列；且 Linux 默认单个队列最大消息数为 MSGMNI（通常 32），超限会触发 EAGAIN 错误。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
实际选型要看数据模式和生命周期
如果你只是让一个 swoole_process 子进程处理完立刻回传结果（比如图片压缩、JSON 解析），用 pipe 最直接：write() → read() 两步搞定，无状态残留。
但如果是异步任务调度（比如多个 Task 进程消费同一批日志写入），就必须用 message_queue —— pipe 无法一对多广播，也无法持久化待消费消息。
性能差异在小数据（10KB 数据时，pipe 的内存拷贝优势明显，而 message_queue 可能因内核缓冲区限制触发阻塞或截断（msgsnd 返回 -1 并设 errno = EFAULT）。
别忽略 swoole_process->exportSocket() 这个折中方案
当 pipe 太受限、message_queue 又太重时，可以考虑 Unix Domain Socket：exportSocket() 能把 pipe fd 暴露为 socket 地址，配合 stream_socket_client() 在非父子进程间复用，既保留零序列化优势，又突破亲缘限制。
不过它需要手动管理连接生命周期，且不支持消息类型过滤；调试时 netstat -x | grep your.sock 比查 ipcs -q 更直观。
真正容易被忽略的是：所有 IPC 方式在 Swoole 中都依赖事件循环兼容性——pipe 的 read() 默认阻塞，若在协程环境里混用，必须用 co::sleep(0) 让出控制权，否则整个协程调度器卡死。
