swoole_server->task() 默认走多进程任务工作池而非多线程；仅当 task_worker_num > 0 且 task_thread_num > 0（Swoole v4.8.0+）时才启用线程模式，此时 onTask 必须同步阻塞、禁用协程API、避免全局变量并发修改。
为什么 swoole_server->task() 不一定走多线程
默认情况下，Swoole 的 task 机制不等于“多线程执行”——它走的是**独立的异步任务进程池**（task_worker），不是线程。哪怕你启用了 enable_coroutine => true 或设置了 task_enable_coroutine => true，只要没显式启用 thread_num > 0 并配合 task_worker_num 调整，就和线程无关。
常见错误现象：top 看不到额外线程、strace 没有 clone 调用、ps -T 显示线程数不变——说明你还在用默认的多进程 task 模式。
- 只有在 Swoole v4.8.0+ 且启用
task_thread_num（注意不是thread_num）时，才真正启用任务线程池 -
task_worker_num控制的是进程数，task_thread_num控制每个 task 进程内开几个线程（默认为 0） - 线程模式下，
task回调函数必须是同步阻塞风格（不能co::sleep、不能yield），否则会卡死整个线程
task_thread_num 怎么设才有效
这个配置只在 swoole_server 构造时生效，且仅当 task_worker_num > 0 时才有意义。设了 task_thread_num = 4 但 task_worker_num = 0，等于白配。
使用场景：IO 密集但非协程友好（比如某些 C 扩展不支持协程、或调用了 sleep/usleep）、需要复用少量线程避免频繁 fork 进程开销。
- 值建议设为 CPU 核心数的 1–2 倍，超过 8 通常收益递减
- 不能大于单个进程能创建的线程上限（Linux 默认一般 1024，可通过
/proc/sys/kernel/threads-max查） - 若同时启用
enable_coroutine => true，务必把task_enable_coroutine => false（线程内不支持协程调度）
new Swoole\Server('0.0.0.0', 9501, SWOOLE_PROCESS, SWOOLE_SOCK_TCP, [
'task_worker_num' => 2,
'task_thread_num' => 4, // 每个 task 进程里起 4 个线程
'task_enable_coroutine' => false,
]);
线程模式下 onTask 回调的限制
线程里的 onTask 不是“随便写逻辑”的地方：它运行在 pthread 上，共享进程内存，但不共享协程上下文，也不受 EventLoop 管理。
常见错误现象：在 onTask 里调用 Swoole\Coroutine::sleep() 直接报错；用 echo 或 var_dump 输出内容丢失；全局变量被多个任务并发修改导致数据错乱。
- 禁止使用任何协程 API（
co::sleep、Co\Http\Client、go等） - 禁止直接操作
$_SERVER、$GLOBALS等超全局变量（线程间可见，非隔离） - 如需共享状态，用
Swoole\Atomic或Swoole\Table，别用普通 PHP 变量 - 返回值必须是可序列化的（因为结果要从线程传回主进程），资源类型（如 file handle、mysqli）会丢失
怎么确认当前 task 确实在跑在线程里
光看配置不够，得验证。最直接的方式是查进程线程树，并在 onTask 中打日志确认执行上下文。
使用场景：上线前压测、排查任务延迟高是否因线程争用、确认是否误入进程模式。
- 执行
ps -o pid,tid,comm -T -p $(pgrep php)，看到多个 TID 对应同一个 PID，且数量 ≈task_worker_num × task_thread_num - 在
onTask回调开头加file_put_contents('/tmp/task.log', "tid:".getmypid()."\n", FILE_APPEND);，观察日志中 PID 是否重复（线程共享 PID，TID 不同） - 若用
gdb attach进去，info threads应该能看到对应数量的线程
容易被忽略的一点：Swoole 的线程池是懒加载的，第一个 task() 调用才会真正创建线程，所以刚启动时查不到，得先触发一次任务。
