FrankenPHP升级后配置不会自动丢失，但frankenphp.yaml、php.ini及扩展路径等需手动同步，否则因路径/权限不匹配导致服务异常；新版可能新增或废弃配置字段，须比对changelog并diff差异，同时确保PHP二进制、ini文件与扩展目录严格对应。
FrankenPHP 升级后配置不会自动丢失，但 frankenphp.yaml 和 PHP 运行时环境（如 php.ini、扩展路径、session.save_path）若未手动同步，就会“看起来丢了”——实际是新进程没读到旧配置，或路径/权限不匹配导致服务启动失败或行为异常。
frankenphp.yaml 不会自动迁移，必须手动检查覆盖
FrankenPHP 没有内置配置升级迁移逻辑。从 v0.12 升到 v0.15 时，frankenphp.yaml 文件仍保留在原位置（通常是项目根目录或 /etc/frankenphp/），但新版可能新增字段（如 metrics、tls.acme）、废弃旧键（如 http.servers 被 http.routes 替代），或调整默认值。
- 升级前先备份：cp frankenphp.yaml frankenphp.yaml.bak
- 查看新版 changelog 或 CHANGELOG.md，确认是否有 breaking changes 标记的配置项
- 不要直接覆盖；用
diff -u frankenphp.yaml.bak frankenphp.yaml对比差异，逐项判断是否保留、改名或删除 - 特别注意
php_options下的extension_dir和extension=行——它们指向的是 PHP 运行时路径，不是 FrankenPHP 自身路径
PHP 配置（php.ini）与 FrankenPHP 的绑定关系容易被忽略
FrankenPHP 启动时会加载指定的 PHP SAPI（通常是 libphp.so 或嵌入式 PHP），但它**不管理 php.ini**。你改了 frankenphp.yaml 里的 php_binary，却没同步 php.ini，就等于换了车引擎但没换油标号。
- 执行
frankenphp --php-version看它调用的是哪个 PHP 二进制文件 - 再运行那个二进制对应的
php --ini，确认Loaded Configuration File路径 - 如果该
php.ini是旧版（比如还在用 PHP 8.2 的配置），而 FrankenPHP 已指向 PHP 8.4，则extension_dir、session.save_path、opcache.enable等全按旧规则生效——可能扩展加载失败、session 写入被拒、OPcache 不启用 - 推荐做法：把新版 PHP 的
php.ini-production复制过去，再按需修改，而非复用旧配置
扩展和 session 目录权限在 FrankenPHP 下更敏感
FrankenPHP 默认以当前用户身份运行（非 www-data），且不自动创建 runtime 目录。升级后常见现象是：首页能打开，但登录后跳转就丢 session，或 mysqli_connect() 报错“function not found”。
立即学习“PHP免费学习笔记（深入）”；
- 检查
phpinfo()页面里extension_dir是否指向新版 PHP 的ext/目录；如果不是，改php.ini并重启 FrankenPHP 进程（kill -SIGUSR2或完整 stop/start） - 确认
session.save_path目录存在、可写，且归属当前运行 FrankenPHP 的用户（不是 root）：例如mkdir -p var/sessions && chown $USER:$USER var/sessions - FrankenPHP 不读取 Apache/Nginx 的
www.conf，所以别指望它继承宝塔或 PHP-FPM 的用户组设置——所有权限必须显式赋予 - 扩展启用状态要双重验证：既在
php.ini中extension=mysqli取消注释，也要在phpinfo()的 “Registered PHP Streams” 或 “modules” 区域看到对应名称
最易被绕过的点是：你以为 FrankenPHP 是个“独立服务”，其实它只是 PHP 的一个嵌入式宿主。它的稳定性完全取决于底层 PHP 的配置是否干净、路径是否绝对、权限是否精确——没有 magic fallback，也没有自动适配。升级后第一件事不是跑业务代码，而是确认 php --ini、php -m、php -r "echo session_save_path();" 三者输出全部符合预期。
