协程调度器已失活或线程被错误绑定到单一核心，需检查coroutine_num是否为0/1、workererror中$signal值及cpu亲和性掩码，确认是否被taskset或systemd误绑定，并按混部、独占或gpu场景选择是否启用cpu亲和性。
Hyperf3.1服务在高并发压测中出现响应延迟抖动、单核CPU持续100%占用且协程数归零，说明协程调度器已失活或线程被错误绑定到单一核心——这不是代码逻辑问题，而是底层调度与硬件资源协同失效。
确认协程调度器是否存活
执行 php ./vendor/bin/swoole-tracker status 查看当前进程的 coroutine_num 值；若长期稳定为 0 或 1，且无新协程创建日志，即判定调度器离线。
检查 WorkerError 回调中 $signal 的值：等于 11 表示段错误（需 core dump 分析），等于 0 且 $exitCode === 255 表示 PHP 致命错误，这两类崩溃都会导致调度器不可恢复终止。
【register_shutdown_function 必须在 onWorkerStart 中注册】 ——每个 Worker 是独立进程，全局注册无效，未在此处注册将无法捕获致命错误。
验证当前进程的 CPU 亲和性掩码
方法一：用 taskset -cp $(pgrep -f 'hyperf') | tail -n 1 获取主进程绑定的核心列表；若输出形如 pid 12345's current affinity list: 0，说明只绑定了 CPU 0。
方法二：直接读取内核接口：cat /proc/$(pgrep -f 'hyperf')/status | grep Cpus_allowed_list；输出 Cpus_allowed_list: 0 同样表示硬性限制。
注意：Hyperf 默认不设置亲和性，若发现被绑定，大概率是启动脚本或 systemd service 文件中误加了 taskset -c 0 类指令。
安全解除 CPU 亲和性限制
第一步：停止当前 Hyperf 实例，避免热更新引发状态冲突。
第二步：检查启动命令链——从 bin/hyperf.php start 上游逐级排查是否被 taskset -c、numactl --cpunodebind 或 systemd 的 CPUAffinity= 覆盖。
第三步：清除所有显式绑定，改用纯净启动：php bin/hyperf.php start；此时内核调度器可自由分配线程到全部可用核心。
第四步：观察 5 分钟内 top -H -p $(pgrep -f 'hyperf') 中各线程的 CPU 分布，应呈现多核均匀负载而非集中于某一个。
按场景决定是否启用 CPU 亲和性
场景一：混部环境（如与 Redis、MySQL 共享物理机）→ 需隔离。用 taskset -c 2-7 php bin/hyperf.php start 将 Hyperf 限定在 CPU 2～7，把 CPU 0～1 留给系统和数据库。
场景二：纯 Hyperf 服务独占整机 → 不设亲和性更优。Swoole 自动适配 NUMA 节点，强制绑定反而破坏缓存局部性。
场景三：GPU 加速任务（如 NCCL 通信）→ 必须绑定。将负责 GPU 数据搬运的 Task Worker 绑定到与 GPU PCI-E 插槽同 NUMA 节点的 CPU 核心，用 sched_setaffinity() 在 Task 进程初始化时调用，而非全局绑定整个服务。
