frankenphp不提供内置worker自愈机制，fatal error会导致php线程终止且不自动重启，需依赖caddy健康检查或systemd等外部守护工具实现进程级恢复。

FrankenPHP 本身**不提供类似 Workerman 那样的主进程监控 + 子进程自动拉起的 Worker 自愈机制**。当 PHP Worker 脚本中发生 Fatal Error（如调用未定义函数、类找不到、语法错误暴露、内存耗尽等），该 PHP 线程会立即终止，且**不会自动重启**——它就停在那里，不再处理新请求。 这和 FrankenPHP 的线程模型直接相关：它采用的是 **“PHP 线程池”模型**，每个请求由一个独立 PHP 线程服务；而 Worker 模式下，一个 PHP 脚本会长期驻留在线程中，循环处理多个请求。但这个“长期驻留”是**应用层逻辑维持的**，不是由 FrankenPHP 运行时强制保活的。

Fatal Error 后发生了什么？

一旦 Worker 脚本执行中触发 Fatal Error：

• 当前 PHP 线程立即终止，堆栈信息输出到 Caddy 错误日志（若配置了 error_log）或标准错误流；
• 该线程从 FrankenPHP 线程池中永久移除，不再参与后续请求分发；
• 其他正常线程继续工作，整体服务仍可用，但 Worker 实例数减少；
• FrankenPHP 不会主动 fork 新线程替代它，也不会重载/重启该 Worker 脚本。

如何实现“自动重启”效果？

要达成类似“崩溃后恢复”的体验，需借助外部机制，目前主流有两类方案：

btpanel phpsite 宝塔面板PHP网站

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

下载

• Caddy 的 health check + worker reload：通过 Caddyfile 中 php 指令的 health_check 参数配合自定义探针脚本，检测 Worker 是否存活；若失败，Caddy 可触发 reload（需搭配 exec 或外部脚本）；但此方式非原生支持，需自行编排。
• 进程守护工具（推荐）：将 FrankenPHP 启动为独立服务，用 systemd 或 supervisord 管理其整个进程。例如配置 systemd 的 Restart=always 和 StartLimitIntervalSec=0，即可在 FrankenPHP 主进程意外退出时自动拉起——注意：这是重启整个 FrankenPHP 实例，而非单个 Worker。

如何捕获并记录 Fatal Error？

虽然无法阻止退出，但可确保留痕定位：

• 在 Worker 入口脚本顶部启用错误日志：
  

  ini_set('log_errors', 'On');<br>ini_set('error_log', '/var/log/frankenphp_worker.log');

• 配合 register_shutdown_function 检查 error_get_last()，仅对 E_ERROR/E_PARSE 等致命类型写入结构化日志（含时间、PID、worker 名）；
• 避免在 shutdown 函数中做阻塞操作（如远程调用），否则可能拖慢线程退出甚至干扰 Caddy 管理。

对比 Workerman 的关键差异

Workerman 的自动重启是内建于其 Master-Worker 架构的底层能力；FrankenPHP 的设计哲学更偏向“轻量嵌入 + 交由 Web 服务器统一治理”。它把进程生命周期交给 Caddy（或你选择的守护进程），自身专注 PHP 执行与线程调度。因此：

• 没有内置 worker_id、pidFile 或子进程退出码监听；
• 监控依赖 Caddy metrics 暴露的 frankenphp_worker_up（表示某 worker 当前是否就绪）、frankenphp_worker_crashes_total（累计崩溃次数）等指标；
• 真正可靠的容错，必须落在 Caddy 配置层或系统服务管理层。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！