这是 FrankenPHP 主进程因 worker 子进程连续崩溃（默认5次/60秒）触发的熔断保护机制，常见于未捕获异常、PHP启动失败或脚本路径/权限错误。
FrankenPHP 报 “too many consecutive failures” 是什么信号
这不是 PHP 代码错误，而是 FrankenPHP 主进程检测到 worker 子进程反复崩溃后主动熔断的保护机制。它意味着：某个 worker（通常是处理 HTTP 请求或消息消费的 PHP 实例）在短时间内连续启动 → 执行失败 → 退出，触发了内置的失败计数器（默认阈值为 5 次/60 秒）。此时主进程拒绝再拉起新 worker，并返回该错误，防止雪崩。
最常见触发场景和对应检查点
这个错误几乎总是由以下三类问题之一引发，按发生频率排序：
-
messenger:consume或frankenphp-worker.php进程因未捕获异常、内存溢出或数据库连接中断而快速退出 - PHP 启动阶段失败：比如
opcache.enable=0导致类加载慢超时、date.timezone未设引发DateTime构造失败、扩展缺失（如pdo_mysql）导致require_once报Fatal error - worker 脚本路径错误或权限不对：Caddyfile 中
php指令指向的public/index.php不存在，或vendor/bin/frankenphp-worker.php被误删/未生成/不可执行
怎么快速定位是哪一行代码或配置在“连环失败”
别猜，直接看 FrankenPHP 启动时的 stderr 输出（不是 access.log 或 error.log）——它会在每次 worker 崩溃后打印最后一行 PHP 错误。关键操作：
- 停止服务：
frankenphp stop或killall frankenphp - 手动前台运行并捕获输出：
frankenphp run --config ./Caddyfile --debug 2>&1 | grep -A5 -B5 "PHP Fatal\|PHP Parse\|Segmentation fault" - 重点盯住输出里重复出现的文件路径和行号，例如：
PHP Fatal error: Uncaught Error: Class "App\Service\SomeService" not found in /var/www/app/vendor/bin/frankenphp-worker.php:42 - 若看到
Segmentation fault，大概率是扩展冲突（如 xdebug + opcache 同时启用）或 PHP 版本与 FrankenPHP 二进制不匹配（如用 PHP 8.4 编译的 FrankenPHP 运行 PHP 8.3 的扩展）
修复后必须做的两件事，否则还会报错
即使改对了代码，旧失败计数器不会自动清零，且残留的僵死 worker 可能仍在后台占资源：
立即学习“PHP免费学习笔记（深入）”；
- 强制清空失败计数器：FrankenPHP 没有重置命令，必须杀掉所有相关进程后再启动。执行
pkill -f "frankenphp\|worker\.php"，再确认ps aux | grep php输出为空 - 删除 worker 缓存文件：如果用了 Octane 集成，
rm -f var/cache/prod/App_KernelProdContainer.php和rm -f var/cache/dev/App_KernelDevDebugContainer.php，避免旧容器中残留的损坏服务实例被复用
最容易被忽略的是：这个错误从不发生在首次启动时，只在 worker 已运行过至少一次后才出现。所以每次修改 frankenphp-worker.php 或核心服务类后，务必先停掉所有进程再启动，不能靠 reload 或 kill -USR2。
