FrankenPHP Worker模式仅优化HTTP请求，不替代队列消费者；messenger:consume或queue:work必须作为独立CLI进程，由supervisord、systemd等外部进程管理器启动和守护，二者进程隔离、环境独立、信号处理互不影响。
不能。FrankenPHP Worker 模式完全不替代队列消费者，它只处理 HTTP 请求生命周期；messenger:consume 或 queue:work 仍是必须独立运行的 CLI 进程。
Worker 模式和队列消费者根本不是同一类进程
FrankenPHP 的 worker 是常驻的 PHP-FPM 衍生进程，专为接收并响应 HTTP 请求设计。它调用 frankenphp_handle_request()，复用 opcache 和预加载类，但每次请求仍重建运行时（$_GET、$_POST、对象实例等）。而 messenger:consume 是标准 CLI 命令：加载完整框架、初始化 Doctrine、连接 Redis/AMQP、监听 transport、手动处理消息——它不走 HTTP SAPI，也不受 FrankenPHP 的 worker 生命周期管理。
- 你启动
frankenphp serve或frankenphp-worker --script worker.php，不会自动拉起任何队列进程 - worker.php 里写
exec('php bin/console messenger:consume')是错的：子进程无法继承信号，且会脱离进程管理 - 试图在 worker 循环里
pcntl_fork()启动消费者，会导致 SIGTERM 丢失、连接泄漏、日志混乱
为什么有人误以为能替代？
常见混淆点来自“常驻”二字。FrankenPHP worker 常驻的是 HTTP 处理能力，不是通用后台任务容器。Swoole 或 RoadRunner 才提供真正的多角色常驻（HTTP + queue + timer），但 FrankenPHP 没这个抽象层。
- worker 模式下
$_ENV来自.env文件或系统环境，而 Web 请求可能已通过 opcache 缓存了旧的 DSN —— 导致messenger:consume连不上 Redis，但网页发消息正常 - worker 进程里
define('APP_ENV', 'prod')不会影响 CLI 进程，两个环境配置必须完全隔离同步 - 使用
--no-reset模式时，CLI 消费者需自行确保 EntityManager 等服务未因长连接失效，worker 模式对此无感知也无协助
Docker 中信号传递失败是高频故障点
在容器里直接跑 php bin/console messenger:consume，若没设为 PID 1，SIGTERM 根本收不到，导致 docker stop 后消费者静默卡死。
立即学习“PHP免费学习笔记（深入）”；
- 错误写法：
command: sh -c "php bin/console messenger:consume"→sh成 PID 1，信号被吞 - 正确写法：
command: ["exec", "php", "bin/console", "messenger:consume", "async", "--time-limit=3600"] - 更稳妥做法：用
supervisord或 systemd 管理，配合--stop-when-empty+ 健康检查，避免无限挂起
真正要记住的只有一条：FrankenPHP 的 worker 脚本里，永远不要尝试启动、fork 或 exec 队列消费者。它和队列之间，必须保持物理隔离与进程边界 —— 这不是限制，而是稳定性的前提。
