Swoole的SWOOLE_PROCESS和SWOOLE_BASE是两种核心运行模式：PROCESS模式采用Master-Manager-Worker多进程架构，连接与处理分离，具备容错性；BASE模式为单线程事件循环，Worker自管连接，无进程隔离，崩溃导致连接中断。
PHP 本身没有 Server/Client 运行模式之分，Swoole 的 SWOOLE_PROCESS 和 SWOOLE_BASE 才是真正影响服务行为的两种运行模式——常被误称为“Server 模式”和“Client 模式”，但这个说法不准确，也容易和 Java 的 -server/-client JVM 参数混淆。
SWOOLE_PROCESS 模式下连接与处理分离
这是 Swoole 默认且推荐的生产环境模式。主进程（Master）负责监听、分发连接，Worker 进程只专注业务逻辑处理。
-
SWOOLE_PROCESS启动后必然存在 Master + Manager + N 个 Worker 进程，即使worker_num = 1也会创建 Manager - Reactor 线程在 Master 进程中接收数据，再通过 UnixSocket IPC 转发给 Worker，因此连接生命周期独立于 Worker 进程
- 某个 Worker 崩溃时，已建立的 TCP 连接不会断开，Manager 会拉起新 Worker 继续处理后续请求
- 适合长连接、高并发、需稳定性的场景，比如 IM、实时推送、游戏网关
- 注意：IPC 通信带来约 5%~10% 的性能损耗，但换来的是容错性和负载均衡能力
SWOOLE_BASE 模式下所有逻辑由 Worker 自己扛
它更接近 Node.js 或 Nginx 的单线程事件循环模型，没有 Master 进程参与调度，每个 Worker 自己 accept、recv、send。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 构造
Swoole\Server时显式传入SWOOLE_BASE，例如：new Swoole\Server('0.0.0.0', 9501, SWOOLE_BASE) - 不启用 Manager 进程，
worker_num仅控制 Worker 数量，但每个 Worker 都要竞争 accept 新连接 - 一旦某个 Worker 因致命错误退出，它手上的所有 TCP 连接会立刻中断，无自动恢复机制
- 适合短连接、计算密集型、低延迟要求且能接受连接抖动的内部服务（如本地 RPC 中转）
- 没有 IPC 开销，吞吐略高，但稳定性代价明显——线上服务慎用
别把 Swoole 模式和 JVM 的 client/server 混为一谈
Java 的 -client / -server 是 JVM 启动参数，影响 JIT 编译策略和默认堆大小；而 Swoole 的 SWOOLE_PROCESS / SWOOLE_BASE 是 PHP 扩展内部的进程模型开关，二者完全无关。
- 你在 PHP 中运行
php server.php，底层用的是哪个 JVM？根本没 JVM - 检查当前 Swoole 模式，看代码里
new Swoole\Server(...)的第三个参数，不是看java -version输出 - 某些文档或博客误将
SWOOLE_PROCESS称作 “Server 模式”，纯属命名误导，官方文档从不这么叫
真正关键的不是“选哪种模式”，而是你是否理解连接生命周期、错误传播路径和资源隔离边界——这些决定了故障会不会扩散、监控指标是否可归因、扩容时要不要重连。多数人踩坑，都始于没意识到 SWOOLE_BASE 下一个 exit 就等于 kill 掉一批活跃连接。
