队列任务异常未重试，主因是框架仅对特定异常（如pdoexception）自动重试，而invalidargumentexception等业务异常默认不重试；需改用runtimeexception或实现shouldberetried接口，并避免依赖set_exception_handler。
任务执行中抛出的异常为什么没被重试？
队列任务失败却不重试，最常见的原因是异常没被框架识别为“可重试错误”。比如 PDOException 或 ConnectionException 通常会被自动重试，但 InvalidArgumentException、LogicException 这类业务逻辑异常默认直接归档失败。
检查你的任务类里是否用了 throw new InvalidArgumentException() 这类明确表示“参数错、不该重试”的异常；如果是网络超时、Redis连接中断等场景，应改用更具体的可重试异常类，或在 catch 块里手动 throw new RuntimeException($e->getMessage(), $e->getCode(), $e) 并确保该异常未被标记为“不可重试”。
- 多数队列框架（如 Laravel Horizon、Symfony Messenger）通过异常类名白名单或注解控制重试行为
- 不要依赖
Exception父类兜底——它通常不触发重试 - 自定义异常类务必继承
RuntimeException或显式实现可重试接口（如ShouldBeRetried）
set_exception_handler 在队列进程里失效？
队列消费者通常是常驻进程（如 php artisan queue:work），它不会像 HTTP 请求那样每次启动都重新注册全局处理器。如果在任务执行过程中抛出未捕获异常，set_exception_handler 可能已丢失上下文或被框架内部覆盖。
真正起作用的是框架对 worker 生命周期的封装：Laravel 在 Worker::process() 内部做了 try-catch，Symfony Messenger 则靠 FailureTransport 和 RetryStrategy 拦截。你写的 set_exception_handler 函数只对当前 PHP 进程有效，而队列 worker 往往会 fork 子进程或复用实例。
- 别在队列任务里动态调用
set_exception_handler—— 它无法穿透到子任务执行栈 - 重写框架的
failed()方法（如 Laravel 的ShouldQueue::failed()）才是可靠入口 - 若用原生 Beanstalkd 或 Redis 驱动，需自行在
while(true)循环外层加try-catch包裹reserve()和执行逻辑
错误告警为什么总延迟或漏发？
告警延迟往往不是代码问题，而是日志落盘和监控采集链路的缓冲策略导致。比如 Monolog 的 StreamHandler 默认使用阻塞写入，而 RotatingFileHandler 在轮转瞬间可能丢弃几条日志；Sentry SDK 若配置了采样率或异步发送，也会造成告警滞后。
更隐蔽的问题是：队列任务崩溃后进程退出，但日志还没 flush 到磁盘。PHP 的 register_shutdown_function 虽然能兜底，但在 SIGTERM（如 supervisor reload）下不一定来得及执行。
- 生产环境必须给日志 handler 加
flush()显式刷新，尤其在failed()方法末尾 - 告警通道优先选支持事务/确认机制的（如 Sentry 的
sync模式、Prometheus Alertmanager 的 webhook retry） - 避免在告警逻辑里做耗时操作（如调用外部 API、查询数据库）——它应该只是写入一条结构化消息
如何区分“该告警”和“不该告警”的异常？
盲目把所有队列异常都发 Slack 或邮件，很快就会被噪音淹没。关键判断点就一个：这个异常是否代表系统状态异常，而非输入或临时抖动。
例如，支付回调任务收到重复 ID 抛出 DuplicateTransactionException，属于预期业务流，只需记录日志；但 RedisException: Connection refused 表示缓存层整体失联，必须立刻告警。
- 按异常类分组设置告警阈值：每分钟
ConnectionException≥3 次才触发 - 在日志上下文中加入
context['queue'] = 'payments'和context['attempt'] = $attempts，方便监控平台过滤 - 永远不要在 catch 块里只写
echo或空return—— 即使不告警，也要至少error_log()一行带堆栈的摘要
队列异常处理最易被忽略的点是：它不像 Web 请求有明确的响应生命周期，所以错误传播路径更隐晦。你得同时盯住三处：任务类本身的 catch、框架 worker 的失败回调、以及进程级的 shutdown hook。少一环，就可能让一次 Redis 故障变成持续数小时的静默失败。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
