Manager进程负责拉起、监听退出、重启Worker/TaskWorker子进程；它不处理业务，仅保障进程存活，避免服务雪崩，自身崩溃会导致整个进程树退出。
进程管理器（Manager Process）是 Swoole 多进程模型中承上启下的关键角色，它不处理业务，但直接决定 Worker 和 TaskWorker 进程的存活质量。没搞懂 Manager，就等于没摸清 Swoole 的“心跳机制”。
Manager 进程到底管什么？
Manager 进程只做三件事：拉起子进程、监听子进程退出信号、按需重启异常子进程。它不参与任何网络 IO 或业务逻辑，也不持有 PHP 脚本上下文。它的存在，是为了让 Worker/TaskWorker 在崩溃后能自动恢复，而不是让整个服务雪崩。
- Worker 进程崩溃时，Manager 会收到 SIGCHLD，然后立即 fork 新 Worker 替代（前提是未超
max_request） - TaskWorker 崩溃同理，但不会影响 HTTP/TCP 请求处理流
- Manager 自身若被 kill -9，整个 Swoole 进程树（包括 Master）都会退出——它不是守护进程，而是 Master 的直属子进程
为什么不能跳过 Manager 直接由 Master 管理 Worker？
因为 Master 进程必须保持轻量和高响应性，它要专注处理 Reactor 线程的 epoll_wait、信号分发、热重启等系统级任务。如果把进程生命周期管理也塞进去，Master 就容易卡在阻塞操作（比如 fork 失败重试、waitpid 调用）中，导致连接积压甚至丢包。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- Base 模式下没有 Manager：所有逻辑都在单个进程里跑，
worker_num只是协程数，此时无进程隔离、无自动重启能力 - 启用 Manager 后，
worker_num和task_worker_num才真正对应 OS 进程数量 - Manager 不会主动杀掉老 Worker，除非配置了
reload_async = true+max_request触发优雅重启
Manager 和 max_request 的协作关系
max_request 是 Worker 进程的“寿命上限”，但它不是由 Worker 自己计数并退出，而是由 Manager 在每次请求结束后检查计数器，并在达标时向该 Worker 发送 SIGTERM。这个过程是异步的，且仅作用于当前 Worker 进程。
- 默认值为 0，表示永不死；设为 1000 后，第 1000 次请求返回后，Manager 就会回收该 Worker 并拉起新进程
- 这个机制是防内存泄漏最朴素有效的手段，但无法解决全局变量污染——因为新 Worker 仍共享同一份代码段和静态资源
- TaskWorker 也有独立的
max_task_request，同样由 Manager 监控和执行回收
真正容易被忽略的是：Manager 对子进程的监控粒度很粗，它只认 exit code 和 signal，不关心 PHP 层的 fatal error 是否已捕获。一旦 Worker 因段错误（SIGSEGV）或 OOM 被系统 kill，Manager 只知道“人没了”，就会无脑拉新进程——这可能导致错误被掩盖，日志里只看到反复 restart，却找不到原始异常点。
