hyperf定时任务由单进程协程调度器crontabdispatcherprocess驱动，不支持多进程；实际并发能力取决于task_worker_num和concurrent.limit配置，并需遵循协程化i/o、禁用阻塞操作、启用锁等最佳实践。
Hyperf 定时任务本身不直接依赖多进程数量，它由 CrontabDispatcherProcess 单进程协程调度器驱动，但实际并发执行能力受底层 Task Worker 资源和任务自身行为制约。所谓“多进程数量限制”，本质是控制定时任务触发后派发到 Task Worker 的并行度，而非给定时器本身配多个进程。
定时任务调度器本身不支持多进程
Hyperf 的 CrontabDispatcherProcess 是一个独立的、单实例的协程进程，负责解析 cron 表达式、判断触发时机、投递任务。它不允许多个副本同时运行——否则会重复执行。框架通过内部锁（如 Redis mutex）或单例机制保障全局唯一性。你不能也不应配置“定时任务开 5 个进程”。
真正影响并发执行的是 Task Worker 配置
当定时任务的 execute() 方法被调用，若其中含耗时操作（如发邮件、写文件、调 API），应主动投递至 Task Worker 处理。此时并发上限由以下两项共同决定：
- task_worker_num：决定了可同时处理任务的独立进程数。建议设为 CPU 逻辑核数 × 1～2（例如 8 核服务器设 8～16），过高会加剧 IPC 压力，过低则排队积压；
-
concurrent.limit（在 async_queue 或 task 配置中）：若任务走异步队列，该参数限制每个消费者进程内真正并行执行的任务数；若直接投递到 Task Worker，则需靠
task_worker_num+ 任务内部协程调度来控并发。
避免定时任务阻塞调度器的三条铁律
即使 Task Worker 足够多，若定时任务写法不当，仍会卡住整个调度链路：
- 禁止在
execute()中使用sleep()、usleep()或未设超时的curl_exec()——这些会阻塞协程，导致后续任务延迟触发； - 所有 I/O 操作必须协程化：用
Co\Http\Client替代 curl，用Hyperf\Database\Connection替代 PDO 直连； - 高频率任务（如秒级）务必启用
$singleton = true和$mutex（Redis 锁），防止同一时刻多个实例并发执行相同逻辑。
验证是否真正“多进程生效”
别只看进程列表里有没有多个 crontab 进程——它本就不该有多个。正确验证方式是：
- 启动时加
-vvv参数，确认日志中Task worker num: 12等数值与配置一致； - 运行中访问
/status接口（需开启 server.status），观察tasking_num是否随任务触发而波动； - 在任务里打点记录开始/结束时间，对比多个任务的实际执行时间差，确认是否真并行而非串行排队。
