laravel队列超时由retry_after与timeout协同控制：retry_after必须大于timeout（建议多10秒），且需按优先级在config/queue.php中为不同redis连接分别配置，避免任务误重试或卡死。

crontab 调度下 PHP 任务超时根本无法捕获

PHP 脚本在 crontab 中超时（max_execution_time 触发）会直接抛出 Fatal error: Maximum execution time exceeded，这不是可捕获的异常，register_shutdown_function 也完全不会执行——引擎已终止，回调无机会触发。你看到的“没日志”“没告警”“进程静默消失”，就是这个原因。

常见错误现象：tail -f /var/log/cron 看不到报错；ps aux | grep php 发现进程突然消失；日志里只有半截输出。

• 别在 crontab 脚本里写 set_time_limit(60) + register_shutdown_function 做兜底——它不工作
• 真正能感知超时的，是操作系统层：crontab 本身不汇报超时，但 Linux 会在进程被 SIGKILL 终止后记录 kernel: Out of memory: Kill process 或 php invoked oom-killer
• 如果用 systemd 托管脚本，可通过 systemctl status your-task.service 查看 ActiveState=failed 和 ExitCode=137（即 SIGKILL），这是超时/OOM 的关键信号

Hyperf/Laravel 队列任务超时必须靠 retry_after 控制

框架级队列（如 Redis 驱动）的“超时”不是 PHP 执行时间限制，而是任务被取出来后，必须在 retry_after 秒内完成并确认（ACK），否则会被重新入队。这个值设太短会导致正常任务反复重试，设太长则故障任务卡死消费者。

典型配置位置：config/queue.php 中的 connections.redis.retry_after，推荐值为实际业务耗时的 2–3 倍，但不超过 Redis 的 timeout（默认 0，即永不过期）和 tcp-keepalive 间隔。

• retry_after = 90：适合多数报表、同步类任务；若任务常卡在 Redis 写入或第三方 API，需同步调大 redis.client.options.timeout
• 不要把 retry_after 和 php.ini 的 max_execution_time 混为一谈——前者是队列协议层语义，后者是 PHP 解释器限制
• Laravel 中 php artisan queue:work --timeout=60 的 --timeout 是 worker 进程单次处理的硬上限，超过会强制 kill 当前子进程，但它不影响 retry_after 的重试逻辑

自动恢复不能只靠重试，得切断故障源头

单纯依赖队列重试（tries=3）解决不了问题：如果任务每次失败都因同一原因（比如 Redis 连接池耗尽、MySQL 死锁、内存泄漏），重试只会让问题恶化，甚至拖垮整个消费者进程。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

真正有效的自动恢复，是分层拦截：

• 在任务 handle() 开头加内存水位检查：if (memory_get_usage(true) > 512 * 1024 * 1024) { throw new RuntimeException('Memory limit exceeded'); }，主动退出而非等 OOM
• 对高风险外部调用（如 HTTP、Redis、MySQL）全部套 try/catch，且 catch 后明确 return 或 throw，避免未处理异常导致协程挂起
• Hyperf 用户务必启用 hyperf-alarm-clock，用 AlarmClock::run(fn() => $this->doHeavyWork(), 300) 包裹核心逻辑——超时直接抛异常，触发队列重试或告警，不等 PHP 自己杀进程
• Linux 层面用 flock 锁住关键脚本，防止 crontab 并发重复拉起：*/5 * * * * flock -n /tmp/mytask.lock -c "/usr/bin/php /app/artisan my:task"

K8s 环境下超时告警必须跨层联动

在容器里，PHP 进程超时往往不是代码问题，而是资源配额触顶后被系统干掉。只看 PHP 日志永远找不到根因。

必须把三类信号串起来才能准确定位：

• 进程层：K8s Event 中出现 OOMKilled 或 BackOff，对应 POD 的 status.containerStatuses.state.terminated.exitCode 为 137 或 143
• 应用层：Hyperf 日志中 check_worker_exit_status 报非零退出码，或 worker PID 在短时间内飙升（如 1 小时内从 1000 到 50000）
• 中间件层：Redis INFO commandstats 显示 cmdstat_zrangebyscore 耗时突增，或 redis-cli llen queues:default 持续 > 1000

告警规则要写成「且」关系，比如：「过去 5 分钟内，POD 出现 OOMKilled 且 同一 POD 的 Hyperf 日志有 check_worker_exit_status 非零」，才真正值得人工介入。单独一条信号，大概率是误报。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！