swoole worker进程不能直接fork子进程，因其默认启用reactor_thread和task_worker协同调度，底层已注册pthread_atfork钩子；worker中调用fork会触发glibc安全检查失败，导致crash并报pthread_atfork: invalid argument或segmentation fault。
为什么 Swoole 的 Worker 进程不能直接 fork 子进程
因为 swWorker 进程默认启用 reactor_thread 和 task_worker 协同调度，底层已调用 pthread_atfork 注册了 fork 钩子；一旦在 Worker 中调用 fork()，会触发 glibc 的 fork 安全检查失败，直接导致进程 crash 并报错：pthread_atfork: Invalid argument 或 Segmentation fault。
实操建议：
- 若真需派生子进程（如执行外部命令），改用
swoole_process::exec()或proc_open()，它们由 Swoole 封装并绕过线程上下文冲突 - 禁止在
onWorkerStart以外的回调（尤其是onReceive）中调用pcntl_fork() - 若必须用
pcntl_fork()，请确保 Swoole 启动前就完成 fork（例如在onWorkerStart里 fork 一次，后续复用子进程），且关闭task_worker避免干扰
如何安全地在 Swoole 中使用 pcntl_fork
不是不能用，而是要用对时机和上下文。Swoole 的多进程模型与 PHP 原生 pcntl 并非天然兼容，关键在于「谁先初始化」——Swoole 的 reactor、manager、worker 等进程结构一旦启动，就会接管信号和线程状态。
实操建议：
- 只在
onWorkerStart回调中 fork，且仅 fork 一次；之后该子进程应脱离 Swoole 生命周期管理（不调用swoole_event_wait等） - 子进程需显式调用
pcntl_signal_dispatch()处理信号，并禁用pcntl_async_signals(true)（Swoole 5.0+ 已默认禁用） - 务必在 fork 后调用
posix_setsid()脱离会话组，避免被 manager 进程误杀 - 子进程内禁止调用任何 Swoole API（如
swoole_timer_tick、swoole_http_client），否则引发内存越界或连接泄漏
Task 进程 vs Worker 进程：何时该用哪个
很多人以为 Task 是“用来跑耗时任务的 Worker”，其实根本区别在于：Worker 是事件驱动、共享 Reactor 上下文；Task 是同步阻塞、完全独立的子进程，不参与事件循环。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
实操建议：
- 需要异步非阻塞 I/O（比如调用 Redis、MySQL、HTTP 接口）→ 用
Co\Redis/Co\Http\Client，放在 Worker 里即可，别扔进 Task - 需要 CPU 密集型计算（如图像处理、加密解密、大数组排序）→ 放到 Task，避免阻塞 Worker 的事件循环
- 需要调用不支持协程的扩展（如
ext-imagick、ext-mbstring某些函数）→ 必须用 Task，否则会导致整个 Worker 卡死 - 注意
task_worker_num不宜设得过大（一般 ≤ CPU 核数 × 2），否则进程切换开销反超收益
Manager 进程挂掉会发生什么
Manager 进程本身不处理业务，只负责监控 Worker/Task 进程状态、转发信号、热重启。它挂了不会立即中断服务，但会丧失进程保活能力 —— 此后任意 Worker 或 Task 崩溃都不会被自动拉起，且 kill -USR1 等平滑重启信号失效。
实操建议：
- 通过
ps aux | grep swoole观察是否存在manager process，缺失即已退出 - 常见诱因是 Manager 在
onManagerStart中抛出未捕获异常，或调用了exit()/die() - 不要在
onManagerStart中做任何阻塞操作（如sleep()、file_get_contents()），它运行在单线程中，卡住即整个 Manager 卡死 - 生产环境建议配合 systemd 或 supervisor 管理主进程，实现 Manager 挂掉后的兜底拉起
真正难调试的，往往不是 Worker 崩溃，而是 Manager 静默退出后，你还在等它帮你拉起新 Worker —— 结果发现请求慢慢变少，最后全 502，却查不到任何错误日志。
