FrankenPHP不提供内置Worker自愈机制，Fatal Error会导致PHP线程终止且不自动重启，需依赖Caddy健康检查或systemd等外部守护工具实现进程级恢复。
Fatal Error 后发生了什么？
一旦 Worker 脚本执行中触发 Fatal Error：
- 当前 PHP 线程立即终止，堆栈信息输出到 Caddy 错误日志（若配置了
error_log）或标准错误流； - 该线程从 FrankenPHP 线程池中永久移除，不再参与后续请求分发；
- 其他正常线程继续工作，整体服务仍可用，但 Worker 实例数减少；
- FrankenPHP 不会主动 fork 新线程替代它，也不会重载/重启该 Worker 脚本。
如何实现“自动重启”效果？
要达成类似“崩溃后恢复”的体验，需借助外部机制，目前主流有两类方案：
-
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 执行与线程调度。因此：
立即学习“PHP免费学习笔记（深入）”；
- 没有内置
worker_id、pidFile或子进程退出码监听； - 监控依赖 Caddy metrics 暴露的
frankenphp_worker_up（表示某 worker 当前是否就绪）、frankenphp_worker_crashes_total（累计崩溃次数）等指标； - 真正可靠的容错，必须落在 Caddy 配置层或系统服务管理层。
