FrankenPHP将WordPress回滚状态源从Nginx、PHP-FPM等五六个环节压缩为Caddyfile、frankenphp.yaml、WordPress文件、数据库及Redis四部分，需同步备份配置与代码并重启进程以确保一致性。
FrankenPHP 不改变 WordPress 备份和回滚的底层逻辑，但显著压缩了「状态来源」的数量——原来要对齐 Nginx、PHP-FPM、系统 PHP 版本、OPcache、.htaccess 规则等五六个环节，现在只剩 FrankenPHP 进程本身 + WordPress 文件 + 数据库 + Redis（如有）这四块。回滚失败率下降，不是因为更简单，而是因为干扰项少了。
FrankenPHP 下 WordPress 的备份必须包含 Caddyfile 和 frankenphp.yaml
传统 Nginx+PHP-FPM 部署中，Nginx 配置和 PHP-FPM 池配置是独立文件，出问题时可以单独改、单独回滚。FrankenPHP 把 Web 服务和 PHP 执行绑在同一个进程里，它的行为完全由两个配置驱动：
-
Caddyfile：定义 HTTPS、重写规则、静态文件路径、反向代理等——它替代了 nginx.conf -
frankenphp.yaml（或命令行参数）：控制 worker 数量、PHP ini 覆盖项、bootstrap 脚本路径——它替代了 www.conf + php.ini
漏备其中任何一个，恢复后可能出现：404（Caddyfile 路由错）、502 Bad Gateway（worker 启动失败）、upload_max_filesize 不生效（frankenphp.yaml 未还原）。
回滚时不再需要同步 PHP-FPM 进程池或系统级 php.ini
以前回滚一个 Laravel 或 WordPress 站点，常要核对三处 PHP 配置是否一致：
立即学习“PHP免费学习笔记（深入）”；
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
- 系统全局
/etc/php/8.1/fpm/php.ini - FPM pool 配置里的
php_admin_value[memory_limit] - Nginx 的
fastcgi_param PHP_VALUE覆盖项
FrankenPHP 内部只认自己加载的 php.ini（默认用系统默认路径，但可通过 frankenphp.yaml 的 php_ini_path 显式指定），且不走 FastCGI 协议，所以 Nginx 层面那套 fastcgi_param 完全失效。回滚时只需确保 frankenphp.yaml 和你备份的 php.ini 一起还原，其余 PHP 配置项无需操心。
Worker 模式开启后，OPcache 和框架 bootstrap 状态会跨请求残留
这是最容易被忽略的差异点。FrankenPHP 默认以 CGI 模式运行（每次请求新建 PHP 生命周期），但一旦启用 worker 模式（通过 frankenphp.yaml 设置 workers: 4），PHP 进程就会长驻，OPcache 缓存、Laravel/Symfony 容器、甚至全局变量都可能被复用。
这意味着：
- 回滚代码后，必须重启 FrankenPHP 进程（
systemctl restart frankenphp或kill -SIGTERM主进程），否则旧版本的类文件仍可能从 OPcache 中命中 - 如果旧版代码依赖某个已删除的数据库字段，而新版本迁移脚本已执行过，此时仅回滚 PHP 文件不解决根本问题——数据库结构仍是新的，这点和传统部署一样，但更容易误判为“回滚成功”
- WordPress 插件更新后崩溃，用 FTP 移动
wp-content/plugins/xxx目录即可，但若插件内部有register_shutdown_function或常驻 worker 初始化逻辑，可能需额外清空wp-content/cache/或重启 FrankenPHP
FrankenPHP 让回滚路径变短，但没消除“状态一致性”的本质难题；它只是把原本分散在四个进程里的状态，收束到一个二进制加三份配置里——备份时少漏一项，恢复时就少一个黑盒。
