frankenphp 的 caddyfile 修改后无需手动重启，但仅限 frankenphp run 模式下满足热重载三条件：使用 run 命令启动、caddyfile 在工作目录或显式指定且非符号链接、修改不触及进程级配置（如 num_threads、worker 块、php_ini 指令等），否则仍需手动重启。
FrankenPHP 的 Caddyfile 修改后是否需要手动重启？
不需要每次改完都手动 kill 或 frankenphp run 重启——只要配置本身支持热重载，FrankenPHP 就能自动生效。但这个“自动”有明确前提：你得用 frankenphp run 启动（而非 frankenphp server），且 Caddyfile 中没禁用 auto_https 或其他触发 reload 的机制。
Caddyfile 热重载实际生效的三个条件
热重载不是默认无脑开的，它依赖底层 Caddy 的配置变更监听机制。以下三点缺一不可：
-
frankenphp run模式启动：只有该命令会监听文件变化并触发 reload；frankenphp server是静态加载一次后就不再检查文件改动 - Caddyfile 必须放在当前工作目录，或通过
-c显式指定路径，且路径不能是符号链接（Caddy 不监控 symlink 目标） - 修改保存后，FrankenPHP 需在几秒内检测到 mtime 变更——如果你用 vim 编辑且开启了
backupcopy=yes，它会先删原文件再写新文件，导致 Caddy 认为“配置文件消失”，触发 full restart 而非 reload；建议设backupcopy=no或用:set nowritebackup
哪些修改会强制 full restart 而非 reload？
reload 只适用于路由、中间件、encode、php_server 参数等“运行时可变”的配置项；一旦触及进程级设置，Caddy 就必须重建整个服务实例：
- 修改全局块中的
{ frankenphp { num_threads 4 } }—— 线程数变更需重启 - 新增或删除
worker { file ... }块 —— worker 生命周期由主进程管理，配置增删即重建 - 改动
php_ini opcache.enable 1这类影响 PHP 初始化的指令 —— 内嵌 PHP 运行时已启动，无法动态重载 ini - 把
root public/改成root /var/www/app/public/且路径权限/存在性变化 —— Caddy 在 reload 时会校验 root 是否可读，失败则 fallback 到 full restart 并报错open /var/www/app/public: permission denied
验证热重载是否真生效了
别只看终端没报错就以为 reload 成功。最直接的办法是观察日志和指标端点：
- 启动时加
--log-level debug，改完 Caddyfile 后留意是否出现reloading config日志行，而不是shutting down+starting - 访问
http://localhost:2019/metrics，查caddy_config_last_reload_success_timestamp_seconds时间戳是否更新 - 用
curl -I http://localhost看响应头里Server字段是否仍为Caddy—— 如果变成nginx或空，说明 reload 失败，FrankenPHP 已静默退回到 fallback 模式（极少见但可能）
真正容易被忽略的是：Caddyfile 里所有 {$ENV_VAR} 占位符在 reload 时不会重新求值，它们只在首次启动时展开。改环境变量后，必须手动重启才能生效。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
