swoole中真正常用、稳定、可落地的ipc方式只有三种：pipe（管道）、msgqueue（system v消息队列）、swoole\table（共享内存封装）；pipe依赖fork后文件描述符继承，仅限父子进程；msgqueue需固定key防冲突；table基于shmget+自旋锁，字段定长、线程安全。
直接说结论：Swoole 中真正常用、稳定、可落地的 IPC 方式只有三种——pipe（管道）、msgqueue（System V 消息队列）、Swoole\Table（共享内存封装）。其他如信号、Unix socket、自建 shmop 等，要么能力残缺，要么维护成本高，生产环境慎用。
为什么 pipe 只适合父子进程通信？
因为 swoole_process 创建子进程时，默认调用 socketpair(AF_UNIX, SOCK_STREAM, 0, ...) 构建一对双向 Unix 域套接字，底层是内核 socket 缓冲区，不是传统 pipe。它依赖 fork 后的文件描述符继承机制——子进程从父进程“继承”了读/写端 fd，一旦进程无亲缘关系（比如两个独立启动的 worker），fd 就不共享，write() 会直接 Broken pipe。
- 错误现象：
PHP Warning: Swoole\Process::write(): write() failed, Error: Broken pipe[32] - 不能跨
exec启动的进程，也不能用于 Manager 进程和 Worker 进程之间（除非显式传递 fd） - 单条消息建议控制在 64KB 以内，超长可能阻塞或被截断（取决于内核
net.core.wmem_default） - 注意关闭冗余端：父进程写完要
close($pipe[1])，否则子进程read()不会返回 EOF
msgqueue 的 key 和权限怎么设才不踩坑？
msgqueue 底层调用 msgget()，需要一个系统级唯一的 key。很多人直接传 ftok(__FILE__, 'a')，结果上线后多实例冲突——因为 ftok 仅对同一文件路径 + 同一 proj_id 才生成相同 key，而容器或不同部署路径下 __FILE__ 不一致，极易重复 key 导致 msgget: Invalid argument 或数据错乱。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 推荐做法：用固定数字 key（如
0x12345678），配合0666 | IPC_CREAT权限位 - 必须检查
msgqueue->push()返回值，失败时errno可能是EAGAIN（队列满）或EACCES（权限不足） - 队列默认最大 10 条（
msg_qbytes），需提前用ipcs -q查看，必要时用ipcs -q -i [qid]+ipcs -q -s调整 - 别在协程中调用
msgqueue，它不是协程安全的，会阻塞整个协程调度器
Swoole\Table 共享的是什么内存？为什么比 raw shmop 更安全？
Swoole\Table 是对 System V 共享内存（shmget）+ 自旋锁的封装，所有 worker 进程通过同一个 key 映射到同一块物理内存页。但它不共享 PHP 变量本身，只共享结构化字段（string、int、float），且字段长度在创建时就固定（如 ['uid' => 'int', 'name' => 'string:64']）。
- 优势在于自动处理并发写：每个字段写入前加自旋锁，避免竞态；而 raw
shmop完全无锁，shmop_write覆盖写可能撕裂数据 - 注意
Table容量上限由$table->size决定，不是 PHP 内存限制，而是 shm 内存段大小，超限会Segmentation fault - 不能存复杂结构（如嵌套数组、对象），
serialize()后写入 string 字段是常见 workaround，但需自行保证长度不溢出 - 重启服务后内存未释放？执行
ipcs -m找到对应shmid，再ipcrm -m [shmid]清理
真正难的不是选哪种方式，而是判断「哪类数据该走哪条路」：高频小状态（在线数）用 Table，异步任务指令用 msgqueue，父子间临时透传配置用 pipe。混用或强行复用某一种，迟早遇到 EINVAL、ENOMEM 或静默数据损坏。
