优先查队列监听日志和PHP错误日志以区分“进程退出”或“卡死”，再结合时间戳、堆栈及系统资源定位根因：一查进程状态（ps/supervisorctl）；二查三类日志（重定向输出、php_error.log、runtime/log）；三辨常见原因（数据库/Redis断连、OOM、未捕获异常）；四配debug、异常模板、内存限制与健康检查。
ThinkPHP6.1 队列消费程序异常中断，优先查 队列监听日志 和 PHP 错误日志，而不是只看应用日志。关键在于确认中断是“进程退出”还是“卡死”，再结合日志时间戳、错误堆栈和系统资源判断根因。
一、确认消费进程是否真的中断了
执行以下命令检查 worker 进程是否存在：
- ps aux | grep think:queue:work —— 看主进程和子进程是否还在运行
- kill -0 [PID] —— 对疑似存活的 PID 发送信号验证是否可响应
- 如果用 supervisor 管理，运行 supervisorctl status 查看进程状态（RUNNING / STOPPED / FATAL）
二、重点排查三类日志位置
ThinkPHP6.1 默认不自动记录队列消费细节，需主动配置或定位已有输出：
- 队列命令标准输出/错误重定向日志：启动时若用了 php think queue:work --daemon > /path/to/queue.log 2>&1，就直接查这个文件，里面会有 PHP Fatal Error、Exception 抛出、内存溢出（Allowed memory size exhausted）等原始报错
- PHP 错误日志（php_error.log）：由 php.ini 的 error_log 指定路径，所有未捕获异常、致命错误都会写入，重点关注 PHP Fatal error、Segmentation fault、Out of memory
- ThinkPHP 日志（runtime/log/*.log）：默认仅记录 Log::info() 等显式调用，若你在 Job::handle() 中没加日志，这里可能为空；可临时在 handle 开头加 Log::info('job start', ['job' => $this->jobId()]); 辅助定位中断点
三、常见中断原因与对应日志特征
根据日志内容快速缩小范围：
立即学习“PHP免费学习笔记（深入）”；
- 数据库连接丢失：日志出现 SQLSTATE[HY000]: General error: 2006 MySQL server has gone away 或 PDOException，说明长连接超时断开，需在 job 中手动 reconnect 或配置 'options' => [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION] 并捕获重试
- Redis 连接异常：如 Redis server went away、Connection refused，多因 Redis 重启、超时或连接数满，检查 queue.php 中 'expire' 和 'retry_after' 是否合理
- 内存耗尽（OOM）：日志末尾突然截断，系统层可能有 Killed process 记录（查 dmesg -T | grep -i "killed process"），需限制单个 job 内存使用或拆分大数据处理
- 未捕获异常导致进程退出：日志里有完整异常堆栈但无后续，说明该 job 执行失败后 worker 退出（尤其未开启 --tries 或 --delay），建议统一 try-catch + Log::error 并主动 release 或 fail
四、增强日志可观测性的实操建议
避免下次排查抓瞎，上线前加这几项：
- 在 app/queue.php 中启用详细调试：'debug' => true（仅开发环境）
- 为每个 Job 类的 handle() 方法包裹统一异常处理模板，强制记录 job ID、异常消息、trace
- 用 --memory=128 和 --timeout=60 显式限制资源，配合日志中 “Memory usage” 提示判断泄漏
- 对关键外部依赖（MySQL/Redis/HTTP）添加健康检查钩子，失败时立即写日志并 throw Exception
不复杂但容易忽略：很多中断其实只是 supervisor 重启策略没配好，或 Linux OOM Killer 杀了进程，先看系统日志和进程状态，再翻代码。
