Hyperf定时任务由单个CrontabDispatcherProcess协程驱动，不支持也不需worker_num等多进程参数；核心配置在crontab.php中仅含enable、scan、timezone等字段，真正影响执行的是max_coroutine、task_worker_num及Redis分布式锁。
Hyperf 中通过配置文件定义定时任务时，不涉及“多进程参数”——定时任务本身由单个 CrontabDispatcherProcess 进程驱动，它基于协程定时器调度，不是靠增加进程数来提升并发。所谓“多进程”误解常源于混淆了 task_worker_num、自定义 Process 或传统 Worker 模型。Hyperf 3.x 的定时任务调度是轻量、单进程、高并发的协程行为。
crontab.php 配置项说明（核心字段）
配置文件 config/autoload/crontab.php 控制的是任务注册与全局开关，关键字段如下：
-
enable：布尔值，决定是否启用整个 Crontab 调度器（默认
true） -
scan：数组，指定扫描注解任务的命名空间路径（如
['App\Crontab']），不影响性能，仅控制类发现范围 -
timezone：字符串，设置时区（如
'Asia/Shanghai'），影响 cron 表达式解析时间点 -
crontab：数组，存放手动配置的任务实例（
Hyperf\Crontab\Crontab对象），每个任务含name、rule、callback、memo等属性
没有 worker_num、process_num 等“并发参数”
你在 crontab.php 里找不到也**不应该添加**以下字段：
-
worker_num：Hyperf 3.0+ 已彻底移除，写入无效，Swoole 5+ 协程 Server 下无传统 Worker 进程概念 -
process_num或crontab_process_num：不存在，框架不提供“多个 Crontab 进程”选项 -
max_request、max_conn：属于 HTTP/TCP Server 配置（server.php），和定时任务无关
试图在 crontab 配置中加这些参数，既不会生效，也会造成维护困惑。
真正影响定时任务执行能力的因素
虽然 Crontab 自身不配置多进程，但它的稳定运行依赖于整体服务架构的协同：
-
CrontabDispatcherProcess 必须注册：需在
config/autoload/processes.php中显式加入：Hyperf\Crontab\Process\CrontabDispatcherProcess::class -
协程资源充足：确保
max_coroutine（在server.php中）足够支撑高频任务（如秒级任务 + 多个并发执行逻辑） -
异步任务卸载能力：若
execute()内有耗时操作（如 DB 查询、HTTP 调用），应投递到TaskWorker，此时需合理配置task_worker_num（非 crontab.php 文件） -
分布式锁保障唯一性：多实例部署时，靠
$mutex = ['type' => 'redis']防重复，这依赖 Redis 连接池配置，而非进程数
为什么不用多进程跑定时任务？
Hyperf 的设计哲学是“单进程 + 协程调度”：
- 一个
CrontabDispatcherProcess可同时管理成百上千个定时规则，靠协程 Timer 实现毫秒级精度扫描 - 多进程反而引入 IPC 开销、状态同步难题，且无法共享内存中的任务元数据
- 任务执行体（
callback）本身可异步化、可投 Task、可加锁，扩展性已在应用层解决
强行拆成多个 Crontab 进程，既无必要，也无框架支持。
