swoole多进程是master/manager/worker/taskworker四层os进程结构：master仅启动manager、创建reactor线程池、监听信号；manager专管worker/taskworker启停与故障自愈；worker需加锁或日志进程避免并发写文件；taskworker适合耗时同步任务但不适用高频或实时场景；协程运行于worker内，不跨进程，共享变量限于同worker。
直接说清楚：Swoole 的多进程不是“多个 PHP-FPM 进程”那种简单复制，而是 Master/Manager/Worker/TaskWorker 四层分工明确、职责隔离的 OS 进程结构——面试官听懂这句，基本就过了。
Master 和 Manager 进程到底谁管什么？
Master 是真正意义上的主控进程，只做三件事：启动 Manager、创建 Reactor 线程池、监听信号（如 SIGTERM）。它不执行任何 PHP 代码，也不处理业务逻辑。
Manager 是 Master 派出的“包工头”，专管 Worker 和 TaskWorker 进程的生命周期：拉起、回收、重启。一旦某个 Worker 进程异常退出，Manager 会立刻 fork 新进程补上——这个机制是 Swoole 实现“平滑重启”和“故障自愈”的底层保障。
常见错误现象：swoole_server->reload() 后连接中断、max_request 触发时日志断续，往往是因为误以为 Manager 会自动 reload 所有子进程，其实它只负责进程启停，PHP 层逻辑是否重载得看 Worker 自己怎么写。
Worker 进程为什么不能直接写文件？
每个 Worker 是独立的 OS 进程，持有各自的 FILE* 句柄和内核文件偏移量（offset）。用 fopen($file, 'a') + fwrite() 并发写同一文件，本质是多个 write() 系统调用竞争，Linux 不保证原子性（尤其超 PIPE_BUF 时），结果就是日志错行、覆盖、甚至整条丢失。
正确做法只有两种：
- 所有 Worker 统一通过
stream_socket_client('unix:///tmp/log.sock')把日志发给一个专用的日志进程（用Swoole\Process启动），由它串行写入 - 必须本地写，则每个 Worker 必须显式调用
flock($fp, LOCK_EX)加锁，且确保所有进程用同一锁文件路径、同一打开模式（不能用'c'模式）
别信 file_put_contents($file, $data, FILE_APPEND) —— 它底层还是 fopen+fwrite，没加锁，照样丢数据。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
TaskWorker 进程适合干啥，不适合干啥？
TaskWorker 是同步阻塞模型，专为耗时、非 IO 密集型任务设计：比如发送邮件、生成 PDF、调用第三方 HTTP 接口（注意：要用 Swoole\Coroutine\Http\Client 而非 cURL，否则协程失效）、写数据库慢查询。
不适合的场景：
- 高频小任务（如每秒几千次计数更新）——TaskWorker 进程数有限，容易积压，反而拖慢 Worker
- 需要实时返回结果的任务——
taskwait()会阻塞当前 Worker，不如改用协程 +go()异步处理 - 依赖全局状态的任务（如操作
static变量或$GLOBALS）——TaskWorker 是独立进程，无法共享内存，变量不互通
一个常被忽略的细节：task_worker_num 设太高会浪费内存，设太低会导致任务队列堆积；建议从 cpu_count * 2 开始压测，观察 swoole_server->stats() 中的 task_queue_num 是否长期 > 0。
协程和多进程的关系，一句话讲透
协程运行在 Worker 进程内部，是单线程下的用户态调度；多进程是 OS 层面的并行资源隔离。二者不冲突，但协程无法跨 Worker 迁移——你在 Worker A 启动的协程，永远只能在 Worker A 里执行完，哪怕它 sleep 了 10 秒，醒来也还在同一个进程里。
这意味着：
- 协程间共享
static变量是安全的（同进程），但跨 Worker 共享必须走 IPC（如msgqueue或 Redis） -
max_request是按 Worker 进程计数的，不是按协程；一个 Worker 处理完 1000 个请求后退出，它里面所有协程都会被强制终止 - 用
Co::sleep()不会让 Worker “让出 CPU 给别的 Worker”，只是让出当前协程的执行权，Worker 还在继续跑其他协程
最易被忽略的一点：协程的“轻量”只体现在创建开销小，不代表它能绕过 OS 进程限制——CPU 核心数、内存上限、文件描述符数量，最终都卡在 Worker 进程这一层。
