FrankenPHP 不接管队列或定时任务，二者须独立运行：队列需 Supervisor 守护 queue:work 进程，定时任务应通过系统 cron 每分钟执行 schedule:run，与 FrankenPHP 完全解耦。
FrankenPHP 本身不接管队列或定时任务
FrankenPHP 的核心价值是让 Laravel 的 Web 请求常驻内存（通过 worker 模式），但它不会自动运行 queue:work 或 schedule:run。这两个仍是独立的 CLI 进程，和 FrankenPHP 的 HTTP 服务完全解耦。你不能指望启动 FrankenPHP 就顺带把队列 worker 或调度器拉起来——它们压根不在同一个进程模型里。
队列 worker 必须用 Supervisor 独立守护
FrankenPHP 启动后，Laravel 的队列消费仍需传统方式：一个或多个长期运行的 php artisan queue:work 进程。这些进程必须由外部进程管理器看管，否则崩溃即停、重启即失。
-
supervisor是最稳妥选择：配置[program:laravel-queue]，command 指向php /path/to/artisan queue:work --sleep=3 --tries=3 --max-time=3600 - 不要用
nohup或systemd --user：缺乏崩溃恢复能力，日志难追踪，权限易出错 - 如果项目用了 Redis 驱动，确保
QUEUE_CONNECTION=redis且REDIS_HOST在.env中指向容器内可访问地址（Docker 下常用redis服务名） - worker 数量别盲目设高：FrankenPHP 已承担 Web 流量压力，队列 worker 应根据 CPU 核心数和任务 I/O 特性调优，
numprocs=2起步更稳
定时任务推荐用系统 cron + schedule:run
Laravel 的 schedule:run 命令本身轻量、无状态，每分钟执行一次即可触发所有注册任务，和 FrankenPHP 兼容性最好。它不需要常驻，也不该常驻。
- 在宿主机或容器中配一条标准 cron：
* * * * * cd /path/to/project && php artisan schedule:run >> /dev/null 2>&1 - 避免用
schedule:work+ Supervisor：它虽能毫秒级精度调度，但会额外占用一个常驻 PHP 进程，与 FrankenPHP 的内存优化目标冲突，且增加单点故障面 - 确认时区一致：FrankenPHP 容器、宿主机、Laravel 的
config/app.php中'timezone'必须统一（如'Asia/Shanghai'），否则daily()类任务可能错时 - 调试时手动执行
php artisan schedule:run --verbose，看输出是否列出预期任务——这是验证调度逻辑是否生效的最快方式
FrankenPHP worker 模式下要小心队列任务里的 HTTP 调用
当 Laravel 以 FrankenPHP worker 模式运行时，整个应用常驻，但队列 worker 是另一个独立进程。如果队列任务中调用了 Http::get() 或类似方法，而目标服务也跑在 FrankenPHP 上，容易因 Unix socket 权限、循环 DNS 解析或连接池耗尽导致超时或失败。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
127.0.0.1而非localhost访问同机服务，绕过 DNS 和 socket 权限问题 - 队列任务中发起的 HTTP 请求务必设
timeout（如Http::timeout(10)->get(...)），防止一个卡死任务拖垮整个 worker - 不要在队列任务里调用
Artisan::call('queue:work')或启动子进程——FrankenPHP 不支持 fork，会直接报PCNTL is not available
FrankenPHP 解决的是 Web 层冷启动开销，队列和定时任务的稳定性仍取决于你对 CLI 进程的管控粒度。最容易被忽略的是：以为换了 FrankenPHP 就不用管 Supervisor 或 cron 了——恰恰相反，此时更需要清晰划分职责边界。
