先确认crontabdispatcherprocess是否注册并运行，这是hyperf定时任务不按时执行的最常见静默失效原因；它需在processes.php中显式配置、重启后用ps验证进程存在，且须避免协程阻塞、时区错位及taskworker未启用等问题。
Hyperf Crontab不按时执行，先看CrontabDispatcherProcess是否注册
没注册调度进程，任务压根不会被扫描和触发，这是最常被忽略的「静默失效」原因。Hyperf 的定时任务不是靠 Linux crond 驱动，而是依赖自己启动的独立进程——CrontabDispatcherProcess。它每分钟轮询一次，匹配当前时间并分发任务。
检查点：
- 确认
config/autoload/processes.php中已显式注册：Hyperf\Crontab\Process\CrontabDispatcherProcess::class - 不要只写注释或留空数组；如果用了自定义进程类，需确保它继承了
CrontabDispatcherProcess并正确重写了逻辑 - 重启服务后，用
ps aux | grep CrontabDispatcher确认该进程确实在运行
协程环境下sleep或阻塞操作导致调度卡顿
Hyperf 默认使用协程调度器，而 CrontabDispatcherProcess 是一个长期运行的协程进程。一旦你在某个定时任务里写了 sleep(10)、file_get_contents 同步调用、或未加 go 包裹的阻塞 I/O，整个调度器的 tick 就会被拖慢——下一轮扫描延迟，后续任务全部偏移。
典型表现：
- 本该每分钟执行的任务，实际间隔变成 1分15秒、1分40秒，甚至跳过某次
- 多个任务共存时，后注册的任务延迟更明显
解决方式：
- 禁用任何同步阻塞调用；HTTP 请求改用
Hyperf\HttpClient\Client，DB 查询确保走协程驱动（如pdo_mysql+mysqlnd） - 必须延时？用
co::sleep(10)替代sleep(10) - 耗时操作扔进
TaskWorker：在@Crontab方法中调用$this->container->get(TaskExecutor::class)->execute(...)
Task 进程未启用或配置不足，导致任务堆积
当定时任务逻辑较重（比如导出报表、批量推送），又没走 TaskWorker，就会在 CrontabDispatcherProcess 所在的 Worker 进程中直接执行。这不仅拖慢调度，还可能因超时被 Swoole 强制 kill，或触发 max_coroutine 限制。
验证与调整：
- 检查
config/autoload/processes.php是否启用了Hyperf\Task\Process\TaskWorkerProcess::class - 查看
config/autoload/task.php中worker_num是否 ≥ 2（单 worker 容易瓶颈） - 在
@Crontab注解里加上process="task"显式指定分发策略：@Crontab(process="task", rule="* * * * *") - 注意：TaskWorker 不支持协程上下文，
go、defer、context相关逻辑需提前剥离或改用同步方式
时区与系统时间不同步引发的「时间错觉」
Hyperf 的 Parser 类默认用 date_default_timezone_get() 解析 cron 表达式，但 Docker 容器、Alpine 镜像或未配置 NTP 的服务器，常出现「PHP 认为是 UTC，系统时间却是 CST」这类错位。结果就是：你设的是 0 2 * * *（凌晨2点），但它按 UTC 解析，实际在 CST 时间 10 点才跑。
排查线索：
- 在任务里打印
date('Y-m-d H:i:s T')和Carbon::now()->tzName，对比两者是否一致 - 检查容器是否挂载了宿主机时区：
-v /etc/localtime:/etc/localtime:ro - 确认 PHP 配置中
date.timezone已设为Asia/Shanghai（而非UTC） - 运行
ntpdate -q ntp.aliyun.com看服务器时间偏差是否 > 1s；偏差大就配chrony或systemd-timesyncd
真正棘手的不是「不执行」，而是「看似执行了，但总差几个小时」——这种问题往往要同时核对 PHP 时区、Swoole 启动参数、Docker 时区挂载、宿主机 NTP 状态四层，缺一不可。
