FrankenPHP 运行 Symfony 队列任务异常处理-php教程-PHP中文网

frankenphp不管理symfony messenger消费进程，需独立运行php bin/console messenger:consume；其worker模式仅优化http请求，对cli队列处理无加速作用，环境变量、信号传递、日志配置等须单独适配。

frankenphp 运行 symfony 队列任务异常处理

FrankenPHP 本身不接管 Symfony Messenger 的消费进程，php bin/console messenger:consume 仍需独立运行 —— 这意味着队列异常处理逻辑和传统 FPM 部署完全一致，但启动方式、环境隔离和信号传递容易出问题。

FrankenPHP 只处理 HTTP 请求生命周期（含 worker 模式下的常驻 PHP 应用），它不会自动拉起或管理 messenger:consume 进程。你不能指望 frankenphp serve 启动后消息就自动被消费。

必须手动或通过进程管理器（如 systemd、supervisord）启动 php bin/console messenger:consume async --time-limit=3600
若用 --no-reset 模式，要确保每次消费前容器/服务已初始化完成（例如 Doctrine EntityManager 未因长连接失效）
FrankenPHP 的 worker 模式对 HTTP 请求有效，但对 CLI 命令无影响 —— messenger:consume 仍是标准 CLI 进程，加载完整框架、走完整生命周期

Docker 容器默认只转发 SIGTERM 给 PID 1 进程，而 messenger:consume 在前台运行时会捕获 SIGINT/SIGTERM 并优雅停止。但如果它不是 PID 1，信号可能根本收不到。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

在 Dockerfile 中，避免用 sh -c "php bin/console messenger:consume..." 启动 —— sh 成为 PID 1，信号被它吞掉，消费者收不到
改用 exec php bin/console messenger:consume...，让 PHP 进程直接成为 PID 1
使用 --stop-when-empty 或 --time-limit 配合健康检查，避免无限挂起；不要依赖无超时的纯 --limit

Symfony 在 FrankenPHP worker 模式下会复用已初始化的容器，但 messenger:consume 是全新 CLI 进程，它读取的是 .env 或系统环境变量，而非 worker 进程里已加载的配置缓存。

常见表现：messenger:consume 连不上 Redis，但 Web 请求能正常发消息 —— 因为 Web 端用了 FrankenPHP worker 缓存的 DSN，CLI 端却读错了 MESSENGER_TRANSPORT_DSN 值
确认方式：在 consumer 启动前加一行 var_dump($_ENV['MESSENGER_TRANSPORT_DSN'] ?? 'not set');
修复动作：统一通过 .env 设置，且确保 Docker env_file 或 environment 覆盖项与 Web 层一致；禁用 php bin/console cache:warmup 时的环境混淆（CLI 缓存 ≠ worker 缓存）

Symfony 默认把 console 命令的日志输出到 php://stderr，不落地到 var/log/prod.log 或 var/log/dev.log —— 导致消费者崩溃时，你查不到任何堆栈。

检查 config/packages/prod/monolog.yaml 是否有 console handler，且没被 channels: ['!console'] 排除
显式启用 console 日志落盘：添加 handler 如 console_file，type 设为 stream，path 指向 php://stderr 或独立文件（如 %kernel.logs_dir%/console.log）
启动 consumer 时加 --verbose 参数，可强制输出 debug 级别异常，方便快速定位序列化失败等静默错误