Redis断开本身不会直接导致Hyperf定时任务崩溃，关键在于代码未处理连接异常；需查日志、进程状态和写入测试定位问题，再通过try/catch、专用连接池、健康检查及上下文隔离修复。
Redis断开本身不会直接让Hyperf定时任务进程崩溃，但若任务中未做连接容错、异常未捕获或协程上下文被污染，就可能引发进程退出或卡死。关键不是“Redis断了”，而是“你的代码没扛住断”。
确认是否真因Redis断开导致崩溃
先别急着改配置，用日志和进程状态说话：
- 查 runtime/logs/hyperf.log 末尾，找 Connection refused、Connection reset by peer、redis.exceptions.ConnectionError 等关键词；有则说明Redis确实不可达
- 执行 ps aux | grep 'php.*timer'，看定时任务进程（如
Hyperf\Timer\Process\TimerProcess）是否还在；若进程消失，再结合日志看是主动 exit 还是被 kill - 在定时任务 handle() 开头加一行
file_put_contents('/tmp/timer_start', date('H:i:s') . "\n", FILE_APPEND);，观察是否还能写入——若停止追加，说明进程已退出或卡在某处
修复Redis连接中断引发的连锁崩溃
Hyperf 定时任务默认运行在独立协程中，不共享 HTTP Worker 的连接池上下文，但一旦 Redis 客户端调用失败且未兜底，就容易触发未捕获异常终止进程。必须做三件事：
-
所有 Redis 调用必须包裹 try/catch：尤其在
handle()或execute()中，不能让 ConnectionError 向上冒泡到 Swoole 调度层 - 读操作可重试，写操作禁止自动重试：比如 GET 可尝试 1 次重连后重试，但 SET/INCR/HSET 等写命令一旦失败，应记录告警并跳过，避免幂等风险
-
手动触发连接池刷新：捕获到连接异常后，立即执行
$this->redis->getConnection()->getPool()->release($connection)或调用$this->redis->getConnection()->disconnect()，再让下次调用重建新连接
为定时任务配置专用、健壮的Redis连接池
别复用 default 池。在 config/autoload/redis.php 中新增一个 timer 池，并显式启用健康检查：
- 设置
'max_connections' => 20（够用即可，避免资源浪费） - 开启
'options' => [Redis::OPT_READ_TIMEOUT => -1, Redis::OPT_CONNECT_TIMEOUT => 3.0] - 加入
'health_check_interval' => 30（每30秒探活一次空闲连接） - 在定时任务类中通过
$this->container->get(\Hyperf\Redis\RedisFactory::class)->get('timer')获取该池实例
防止MySQL异常波及Redis协程上下文
很多崩溃表面是 Redis 断，实际源头是 DB 先挂了。例如 MySQL 报 MySQL server has gone away 后事务回滚失败，异常未 catch，后续 Redis 操作在同一协程里执行，底层 Co\Redis 直接报 Connection reset。
- 检查定时任务中是否有 DB 查询 + Redis 操作混写；若有，DB 操作必须独立 try/catch，且失败后清空当前协程的 Redis 上下文（可用
Context::set($key, null)主动清理） - 禁用任何同步 I/O：如
file_get_contents、curl_exec、sleep—— 这些会让协程假死，看起来像“Redis卡住”，实则是调度器失联 - 在任务开头加
if (swoole_get_local_cid() === -1) { return; }，快速规避协程已离线的危险执行
