frankenphp 专注 http 请求处理与 php 常驻执行，不管理队列等后台进程；queue:work 仍需 supervisor 守护，以确保邮件、报表等任务持续可靠运行。
supervisor 在 FrankenPHP 环境下仍然需要，但使用场景和必要性发生了关键变化。
FrankenPHP 本身是 PHP 运行时（基于 SAPI 的嵌入式服务器），它不管理后台长期进程；queue:work 仍是独立的 CLI 进程，与 Web 请求完全隔离。FrankenPHP 启动的是 HTTP 服务端，不是队列消费者——这点常被误读。
queue:work 进程在 FrankenPHP 中不会自动驻留
FrankenPHP 不会启动、监控或重启 php artisan queue:work。你手动执行一次，它就跑一次，退出后任务即停。
常见错误现象：
- 邮件发不出、报表不生成，
redis-cli lrange queues:emails 0 -1显示有任务，但supervisorctl status找不到 worker - 本地开发用
php artisan serve+queue:work手动起一个进程，上线后忘了补守护
这跟是否用 FrankenPHP 无关——哪怕你用 RoadRunner 或 Swoole，只要没配进程管理器，queue:work 就只是个“一次性命令”。
为什么不能靠 FrankenPHP 的“worker 模式”接管队列？
FrankenPHP 的 --workers 参数只控制 HTTP 请求处理进程（类似 PHP-FPM 的子进程池），不运行 Laravel 队列逻辑。
它不调用 queue:work，不监听 Redis 列表，不反序列化 Job 类，也不处理 --tries 或 --max-time。
把队列混进 HTTP worker 里，会导致：
- 请求超时风险（Nginx/Apache 等网关层无法感知队列任务）
- 内存泄漏污染 HTTP 进程（Job 中的静态变量、DB 连接未释放）
- 无法单独扩缩容（邮件队列高峰时该加 4 个 worker，HTTP 流量低时不该连带扩容）
实际部署建议：FrankenPHP + supervisor 分工明确
-
frankenphp负责 HTTP 入口（监听 8000 端口，处理请求） -
supervisor负责queue:work（独立用户、独立日志、按队列拆分 program）
配置要点：
-
user必须与 FrankenPHP 所用用户一致（如www-data），否则可能因文件权限无法读取storage/logs或写缓存 -
numprocs和--queue=xxx仍需按业务拆分，比如emails队列用 2 进程，reports用 1 进程且加--max-jobs=50防卡死 -
stopwaitsecs=3600和killasgroup=true不能省，否则queue:restart信号无法传递给子进程（尤其用了shell_exec或proc_open的 Job）
supervisor 不是历史包袱，而是职责边界清晰的必需品。FrankenPHP 解决了 PHP 的并发模型和冷启动问题，但没接管“后台任务生命周期”——这个空缺，至今没有通用替代方案。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
