setTimeLimit() 在 Laravel 队列中基本无效，因为 queue:work 是长生命周期进程，每次任务执行前 PHP 超时计时器被重置；真正可靠的是任务类的 $timeout 属性或 dispatch()->timeout()。
为什么 setTimeLimit() 在 Laravel 队列里基本没用
因为 PHP 的 set_time_limit() 在大多数队列驱动（尤其是 supervisor + php artisan queue:work）下会被重置或忽略。Laravel 启动的 worker 进程长期运行，PHP 的超时计时器在每次任务执行前会被重置为 0，set_time_limit(30) 实际上只限制单次脚本执行——而队列 worker 不是“单次脚本”，它是循环取任务、执行、再取的常驻进程。
常见错误现象：set_time_limit(5) 写在任务 handle() 里，但任务卡死 2 分钟仍不中断；或者本地开发时看似生效，上线后完全失效。
- 使用场景：你试图用它防止单个任务跑太久，比如调用第三方 API 卡住、文件解析异常、递归没出口
- 根本原因：PHP 超时机制依赖
max_execution_timeini 设置 + 运行时重置，而queue:work是长生命周期进程，set_time_limit()每次都被覆盖 - 兼容性影响：在
sync驱动下可能“看起来有效”，但这只是巧合——它退化成同步调用，不是真实队列行为
真正可控的超时方案：Laravel 自带的 timeout 属性
这是唯一被 Laravel 队列系统原生支持、跨驱动（redis、database、beanstalkd）都可靠的中断方式。它不依赖 PHP 底层超时，而是由 Laravel worker 主动监控任务执行时间，在超限时抛出 Illuminate\Queue\MaxAttemptsExceededException 并标记失败。
- 在任务类里直接定义：
public $timeout = 60;（单位：秒） - 也可在分发时动态指定：
SomeJob::dispatch()->timeout(45); - 注意：该值不能超过队列驱动自身的超时限制（例如 Redis 的
retry_after必须 ≥timeout，否则任务可能被重复执行） - 性能影响：几乎为零，worker 只是在任务开始时记录时间戳，每轮循环检查一次差值
需要更细粒度控制？用 pcntl_alarm() + 信号捕获（仅 Linux）
当你要在任务内部中断某个具体操作（比如一个阻塞的 cURL 请求、大数组遍历），而不是整个任务，就得用系统级信号。这比 set_time_limit() 真实有效，但有硬性限制。
- 必须运行在支持
pcntl扩展的 Linux 环境（Windows/macOS 开发机基本无效） - 不能在 PHP-FPM 或 Apache 模块中使用（会干扰 Web 请求生命周期）
- 示例片段：
pcntl_alarm(10); // 10 秒后发 SIGALRM pcntl_signal(SIGALRM, function () { throw new \Exception('Operation timed out'); }); // 执行可能卡住的操作... pcntl_signal_dispatch(); // 触发信号处理 - 容易踩的坑：忘记调用
pcntl_signal_dispatch()，或在异常后没重置 alarm，导致后续任务误触发
别忘了 supervisor 的 stopwaitsecs 和 killasgroup
即使 Laravel 层做了超时，如果底层进程没被干净回收，僵尸任务仍可能继续跑。Supervisor 是生产环境最常用的队列守护进程，它的配置直接影响超时是否真正落地。
-
stopwaitsecs=10：给 worker 优雅退出的时间，应略大于你的最大$timeout值 -
killasgroup=true：确保 supervisor 杀掉整个进程组（包括子进程，比如你 fork 出来的子任务） - 漏配后果：任务超时后被 Laravel 标记失败，但实际 PHP 进程还在跑，CPU 占满、数据库连接堆积、Redis 队列积压
- 验证方法：
ps aux | grep queue:work看是否有残留进程；supervisorctl status看是否频繁 restart
超时不是加一行 set_time_limit() 就完事的事。它横跨 PHP 运行时、Laravel 队列抽象层、驱动实现、进程管理工具四层，任何一层断掉，都会让“中断”变成幻觉。真正起作用的，永远是那个最贴近你部署环境的配置点。
