Master进程只负责网络事件监听、Reactor线程管理和信号转发，不执行PHP代码；Manager进程专管Worker/TaskWorker的拉起、监控、回收与重启，实现故障自愈和平滑重启。
理解Swoole中Master与Manager进程的分工，是避免服务雪崩、排查连接中断和reload失效问题的前提——它们不是冗余设计，而是职责不可互换的强制角色。
Master进程：只管网络，不碰PHP代码
第一步：启动后立即创建Reactor线程池，绑定监听端口，进入epoll_wait循环等待新连接或数据就绪。
第二步：收到TCP连接请求时，由Reactor线程完成三次握手、建立socket、分配fd，并将该连接注册进事件表。
第三步：数据到达后，Reactor线程读取完整包（按协议解析），通过管道（Pipe）轮询分发给某个Worker进程处理。
第四步：Worker返回响应数据后，Reactor线程负责将数据写回客户端socket，全程不经过PHP用户层。
Master进程【从不执行任何onStart/onReceive等PHP回调】。一旦你在onStart里同步连Redis或sleep(1)，Reactor线程就会卡住，新连接无法accept，已有连接超时断开——此时CPU可能很低，但QPS已归零。
Manager进程：专管Worker生死，不处理任何业务
方法一：进程拉起与监控
① Master启动后，fork出唯一一个Manager进程；Manager再根据worker_num配置，逐个fork出Worker子进程。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
② Manager调用waitpid持续监听所有Worker/TaskWorker退出信号；一旦捕获SIGCHLD，立刻检查退出状态。
③ 若Worker因段错误（signal=11）或内存耗尽崩溃，Manager立即fork一个新Worker补位，保持总数不变。
方法二：平滑重启触发机制
当收到SIGUSR1信号时，Manager开始滚动重启：先向旧Worker发送SIGTERM→等待其自然退出→确认退出后再拉起新Worker→最后清理旧进程残留资源。
【注意：Manager不会主动kill老Worker，除非max_request达标且reload_async = true】。默认情况下，它只响应信号，不干预Worker内部逻辑计数。
为什么不能跳过Manager，让Master直接管理Worker？
因为Master必须保持单线程轻量——它要高频调用epoll_wait、处理信号、分发连接。如果让它同时做fork/waitpid这类阻塞系统调用，一旦fork失败重试或waitpid卡住，整个Reactor事件循环就停摆，连接积压、丢包、超时全部发生。
Swoole强制用独立的单线程Manager承担fork职责，就是为了规避POSIX层面的epoll_ctl: Bad file descriptor陷阱。你在onStart里手动pcntl_fork()，大概率触发这个错误。
Base模式下没有Manager：此时worker_num只是协程数，所有逻辑挤在单个进程里跑，无进程隔离、无自动重启能力——这正是生产环境必须启用Manager的根本原因。
