FrankenPHP配置不生效主因是执行链路不同：需确认Caddyfile是否显式加载、php指令块路径是否正确、worker脚本是否重生成、PHP关键配置是否通过--php-flags显式传入，且必须手动终止旧进程再启动新实例。
FrankenPHP配置改完不生效，不是“没重启”或“配错了”这种模糊判断，而是得盯住它和传统 Nginx+PHP-FPM 完全不同的执行链路——它自己就是 Web 服务器 + PHP 运行时的融合体，没有 fastcgi_pass、没有独立的 PHP-FPM 进程、也不读系统级 php.ini 的所有配置项。改完不生效，90% 是卡在了 Caddy 层解析、PHP 启动参数绑定、或 worker 脚本未重载这三个环节。
确认 Caddyfile 是否被真正加载
FrankenPHP 启动时只认一个 Caddyfile（默认是当前目录下的 Caddyfile），但它不会自动 reload，也不会报错说“文件不存在”。常见误操作是改了别的名字（比如 Caddyfile.dev）或者放错了路径。
- 运行
frankenphp --version确认二进制可用，再执行frankenphp run --config ./Caddyfile显式指定路径，避免依赖默认查找逻辑 - 检查 Caddyfile 里是否用了
php指令块（不是reverse_proxy），且路径指向的是项目 public 目录，例如：root * /var/www/myapp/public - 如果用了环境变量（如
{env.APP_ENV}），确认启动时已导出，FrankenPHP 不会继承 shell 的全部环境，建议用APP_ENV=production frankenphp run方式传入
检查 vendor/bin/frankenphp-worker.php 是否更新
Octane 安装 FrankenPHP 后生成的 vendor/bin/frankenphp-worker.php 是实际执行入口，它硬编码了框架启动逻辑和部分配置。你改了 .env 或 config/app.php，它并不感知；只有重新运行 php artisan octane:install --server=frankenphp 才会重生成这个脚本。
- 执行
ls -l vendor/bin/frankenphp-worker.php，看修改时间是否晚于你改配置的时间 - 手动运行一次：
php vendor/bin/frankenphp-worker.php，观察是否有 Parse error 或 Class not found —— 这说明 worker 脚本本身加载失败，不是 FrankenPHP 的问题 - 若脚本权限不对，补上：
chmod +x vendor/bin/frankenphp-worker.php
验证 PHP 配置是否被 FrankenPHP 实际应用
FrankenPHP 默认忽略系统 php.ini 中的很多指令，尤其 opcache.enable、date.timezone、memory_limit 这些必须显式通过 --php-flags 传进去，否则沿用 PHP CLI 默认值（比如 opcache 默认关、timezone 默认 UTC）。
立即学习“PHP免费学习笔记（深入）”；
- 启动时加上调试参数：
frankenphp run --php-flags "-d opcache.enable=1 -d date.timezone=Asia/Shanghai" - 在路由里加一行
var_dump(ini_get('opcache.enable'), date_default_timezone_get());，确认输出是否符合预期 -
cgi.fix_pathinfo在 FrankenPHP 中无效，别白改；PATH_INFO 支持由 Caddy 的php指令原生保障，无需额外设置
最常被跳过的动作：改完 Caddyfile 或 .env 后，直接刷新浏览器，却没 kill 掉旧进程再 frankenphp run。FrankenPHP 没有 reload 机制，每次都是全新进程，旧的还在 listen，新请求可能打到已失效的实例上。
