ThinkPHP队列任务失败无日志因默认静默运行，需加--verbose参数或配置log驱动；任务卡住多因Redis状态不同步，应检查连接并清理锁；定位原始参数需在构造函数注入上下文并解析failed_jobs表payload。
队列任务失败后根本看不到日志？
默认情况下，ThinkPHP 的 queue:work 命令静默运行，异常被吞掉或只打到系统日志里，根本不会出现在你熟悉的 runtime/log 中。这不是配置错了，是底层监听器没把异常透出到应用层日志通道。
- 加
--verbose参数启动：例如php think queue:work --verbose，能强制输出异常堆栈到控制台 - 在
app/queue.php配置中显式开启日志驱动：'default' => 'log'（不是sync或redis），并确保'log' => ['level' => 'error']已启用 - 别依赖
try-catch包裹整个handle()—— ThinkPHP 队列中间件会提前捕获并重试，你 catch 到的往往是重试后的最终失败，此时原始错误已被覆盖
任务卡在「pending」或「reserved」不执行？
这通常不是代码问题，而是队列驱动状态同步失效，尤其在 Redis 驱动下常见。Redis 里存着任务元数据，但 Worker 进程可能读不到最新状态，或者任务被标记为 reserved 后因崩溃没释放。
- 检查 Redis 连接是否稳定：
php think queue:failed看不到记录？先redis-cli ping确认连通性 - 手动清理残留锁：
redis-cli keys "queue:*:notify" | xargs redis-cli del（慎用，仅调试时） - 避免在
handle()中调用阻塞操作（如sleep()、同步 HTTP 请求），会导致 Redis 连接超时，任务被反复 reserve 又丢弃 - 如果用数据库驱动，确认
jobs表的reserved_at字段有值但attempts不涨，大概率是数据库连接被复用或事务未提交
如何快速定位某次失败任务的原始参数和上下文？
ThinkPHP 默认只序列化任务类名和参数，一旦失败，你看到的只是个 unserialize() 后的对象快照，没有触发时的完整请求环境、用户 ID、甚至日志 trace_id。
- 在任务构造函数中主动注入上下文：
public function __construct($data, $traceId = null) { $this->data = $data; $this->traceId = $traceId ?: uniqid('q-'); } - 重写
__sleep()方法，确保关键字段被序列化（注意不要带闭包或资源句柄） - 失败后查
failed_jobs表，payload字段是 JSON，里面data键才是你传进来的参数；用json_decode($row['payload'], true)['data']提取 - 别直接在
handle()里Log::info($this->data)—— 如果任务重试多次，日志会重复刷屏；改用Log::warning("task failed {$this->traceId}", [...])
重试机制失效：任务失败一次就进 failed_jobs？
ThinkPHP 的重试逻辑依赖两个地方：任务类的 $tries 属性，以及 queue:work 启动时的 --tries 参数，二者取小值。很多人只设了类属性，却忘了命令行参数没跟上。
立即学习“PHP免费学习笔记（深入）”；
- 任务类中必须定义：
protected $tries = 3;（不能是public，否则序列化后丢失） - 启动命令要显式指定：
php think queue:work --tries=3，否则默认为 1 - 若使用
--delay，注意单位是秒，不是毫秒；延迟过长（如--delay=3600）会让任务看起来“消失”，其实是被挂起一小时 - 重试次数耗尽后，
failed_jobs表里的exception字段是最后一次抛出的异常消息，不是第一次；要看首次失败原因，得翻--verbose启动时的实时输出
最麻烦的是任务里用了静态变量或单例对象缓存状态——重试时进程没重启，那些变量还在，导致行为和首次执行不一致。这种 bug 很难复现，只能靠 var_dump(get_included_files()) 和日志时间戳交叉比对。
