Hyperf通过单个常驻的CrontabDispatcherProcess进程统一调度所有定时任务，动态配置本质是热更新内存中的任务列表而非创建新进程；数据库任务经转换后由CrontabManager注册，执行仍由该进程内协程调度器派发。
Hyperf 本身不直接“动态创建进程”来运行每个定时任务，而是通过一个长期运行的 CrontabDispatcherProcess 自定义进程统一调度所有任务。所谓“根据数据库动态创建定时任务”，本质是动态加载和刷新任务配置，而非启动新进程。整个逻辑围绕“单进程 + 配置热更新”展开。
核心机制：CrontabDispatcherProcess 是唯一调度器
Hyperf 的定时任务由 Hyperf\Crontab\Process\CrontabDispatcherProcess 承担，它是一个常驻的协程进程，随主服务启动。该进程内部维护一个任务列表（Crontab[]），并基于 cron 表达式驱动协程定时器执行回调。所有任务都复用这一个进程，不会为每个数据库任务单独 fork 或创建新进程。
- 进程启动时读取初始任务（来自配置文件或数据库）
- 后续变更仅更新内存中的任务列表，不重启进程
- 任务执行仍由该进程内的协程调度器统一派发
数据库配置如何接入调度流程
要让数据库配置生效，关键在于在 CrontabDispatcherProcess 启动前/运行中，把数据库里的启用任务注入到它的任务列表中。常见做法是：
- 在
CrontabDispatcherProcess::handle()开头或初始化阶段，调用自定义服务（如CronConfigService）查询数据库中status = 1的任务 - 将每条记录转换为
Hyperf\Crontab\Crontab实例（设置name、rule、callback等） - 通过
CrontabManager::add($crontab)注册进调度器；若需替换旧任务，先remove()再add() - 为支持运行时变更，可监听数据库配置表的变更事件（如使用 Redis Pub/Sub 或轮询），触发重载
动态更新的安全与平滑性保障
直接修改调度器内存中的任务列表存在并发风险，因此实际方案需兼顾一致性：
- 使用
Atomic或Channel控制重载操作的串行化，避免多协程同时修改任务列表 - 已开始执行的任务不受影响（协程正在运行，不中断）
- 新增任务从下一个匹配时间点开始调度；停用任务会在下次调度检查时跳过
- 建议对
callback字段做白名单校验，防止数据库误写恶意类名导致反序列化风险
为什么不用为每个任务启一个进程
Hyperf 基于 Swoole 协程，强调轻量与高并发。为每个数据库任务单独起进程会带来严重开销：
- 进程创建/销毁成本远高于协程切换
- 内存占用翻倍（每个进程独立内存空间）
- 无法共享连接池（如 Redis、DB 连接）、容器实例等资源
- 违背 Hyperf “单进程多协程”的设计哲学
