先说结论：在Swoole的IPC选型中，pipe和message_queue各有各的适用场景，没有绝对的优劣之分。两者在底层机制、适用场景和性能表现上差异明显，选错了，代码跑起来就像用卡车运自行车——不是不行，但效率别扭。
不妨看几个典型案例：如果进程间通信发生在父子进程之间，pipe绝对是最优解；但如果需要跨进程、跨生命周期的消息传递，message_queue才是真正灵活的选择。
pipe通信为什么快但受限于父子进程关系
pipe的底层是内核提供的字节流通道，无序列化开销、无消息边界管理、不经过内核IPC子系统（比如msgget），纯内存拷贝。这意味着延迟极低，几乎零额外损耗，是Swoole进程间通信中性能最高的方式之一。
但代价也很明显：它只能用于有亲缘关系的进程间通信。说白了，只有通过swoole_process fork出来的子进程才能用pipe跟父进程互通。不是同一家族背景的进程，根本搭不上同一根线，这也是pipe在选型中最大的局限。
一个常见翻车现场：两个独立启动的Worker进程试图用pipe通信——结局是read()阻塞挂起，或者直接返回0。根本原因很简单：没有fork关系，内核根本不认。
还有一个值得注意的细节：pipe默认是SOCK_STREAM类型，数据流式传输，没有边界。如果你需要按数据包来读取，得自己加协议头，或者在1.7.22及以上版本启用SOCK_DGRAM模式（通过$create_pipe = 2）。当然，即使启用这种模式，也不能完全保证消息的可靠投递——虽然在某些场景下已经足够。
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_process子进程处理完任务后立即返回结果，比如图片压缩、JSON解析——用pipe最直接：write() → read()两步就够了，无状态残留，性能最优。
但要是异步任务调度场景，比如多个Task进程消费同一批日志写入操作，那就必须上message_queue。原因很直接：pipe做不到一对多广播，也无法持久化等待处理的消息，而消息队列天然支持这种模式。
性能差异具体怎么体现？以10KB数据为例，pipe的内存拷贝优势非常明显，延迟极低。而message_queue可能因为内核缓冲区限制，出现阻塞或者消息截断的情况——msgsnd返回-1，同时errno被设为EFAULT，此时需要调整系统参数或改用其他IPC方式。
别忽略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)让出控制权，否则整个协程调度器可能直接卡死，这一点在编写高性能Swoole应用时尤其需要注意。
