swoole 4.x 不原生支持 unix socket 作为进程间通信（ipc）机制，仅将其用于网络服务端/客户端；推荐使用 pipe、msg_queue、table 或 channel 等内置 ipc 方式。
Swoole 4.x 版本本身不原生提供基于 Unix Socket 的进程间通信（IPC）封装，也没有内置 Swoole\Process::pipe() 之外的 Unix Domain Socket 进程通信类。它默认的多进程 IPC 方式是：
-
匿名管道（pipe）：适用于父子进程间单向通信，由
Swoole\Process构造时自动创建； -
消息队列（msg_queue）：需开启
--enable-msgqueue编译选项，通过Swoole\Process::push()/pop()使用； -
共享内存（shared memory）：配合
Swoole\Table或Swoole\Memory\Pool实现轻量数据共享； - 信号（signal）与事件回调：用于进程控制，非数据传输。
Unix Socket 在 Swoole 4 中不是标准 IPC 工具，而是作为网络服务端/客户端协议栈的一部分存在（如 Swoole\Http\Server 或 Swoole\Client 可连接 Unix Socket 地址），但不能直接用于 Worker 进程与 Manager/Task 进程之间的内部通信。
✅ 正确用法：Unix Socket 仅作“外部桥梁”，非内部 IPC
如果你确实需要在 Swoole 多进程模型中使用 Unix Socket 通信，常见合理场景是：
- Worker 进程作为客户端，连接外部独立的 Unix Socket 服务（如 Redis、自研守护进程、Node.js 后端等）；
-
Manager 进程启动一个独立的
Swoole\Server监听 Unix Socket，供 Worker 主动连接并发送控制指令或状态上报； -
跨 PHP 进程边界（非父子关系）的通信，比如多个独立
php server.php实例需协同，此时 Unix Socket 是比 TCP 更安全高效的本地通道。
示例：Worker 主动连接 Manager 开启的 Unix Socket 服务
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
// manager 进程中（在 onManagerStart 回调里）
$unixServer = new Swoole\Server('/tmp/swoole-manager.sock', 0, SWOOLE_PROCESS, SWOOLE_SOCK_UNIX_STREAM);
$unixServer->on('receive', function ($server, $fd, $from_id, $data) {
// 处理 worker 发来的指令，如 reload config、获取统计
$server->send($fd, json_encode(['status' => 'ok', 'uptime' => time() - START_TIME]));
});
$unixServer->start();
// worker 进程中（如 onWorkerStart 或定时任务里）
$client = new Swoole\Client(SWOOLE_SOCK_UNIX_STREAM);
if ($client->connect('/tmp/swoole-manager.sock')) {
$client->send(json_encode(['cmd' => 'get_stats']));
$resp = $client->recv();
var_dump(json_decode($resp, true));
}
⚠️ 注意：该方式本质是「进程外通信」，每个 Swoole\Client 连接会新建 socket fd，不属于 Swoole 内置 IPC 机制，也不受 Swoole\Process 生命周期管理。
❌ 不推荐/不可行的做法
- 试图用
stream_socket_server('unix:///tmp/xxx.sock')混合使用 Swoole 进程模型：容易触发 fd 冲突、协程调度异常或fork()后 socket 状态错乱； - 在
onTask/onWorkerStart中复用同一个 Unix Socket fd 跨进程读写：Unix Socket fd 不继承、不可跨 fork 共享，必须各自 connect； - 依赖
socket_*函数手动实现 IPC：绕过 Swoole 事件循环，无法在协程环境安全使用，且易阻塞。
? 替代方案：更轻量、更 Swoole 原生的 IPC 推荐
| 方式 | 适用场景 | 是否需编译选项 | 备注 |
|---|---|---|---|
Swoole\Process::pipe() + write()/read()
|
父子进程简单命令/日志传递 | 否 | 单向，适合 signal-like 控制流 |
Swoole\Table + Swoole\Atomic
|
多 Worker 共享计数器、开关、缓存元信息 | 否 | 内存级，零序列化开销 |
Swoole\Coroutine\Channel |
协程间通信（同进程内） | 否 | 不跨进程，勿混淆 |
msg_queue（启用后） |
需可靠消息投递、支持阻塞 pop | 是（--enable-msgqueue） |
类似 System V，稳定但略重 |
? 提示：Swoole 4.8+ 已支持
Swoole\Process\Pool，可统一管理子进程生命周期，配合msg_queue或Table构建清晰的主从通信结构，比手搓 Unix Socket 更健壮。
Swoole 4 的 IPC 设计哲学是「分层解耦」：进程管理归 Process，网络通信归 Server/Client，数据共享归 Table/Memory。Unix Socket 属于网络层能力，不该越界承担 IPC 职责。用对位置，才能既稳定又高效。
