FrankenPHP缓存目录权限错误需按“属主→目录x权限→文件rw权限”三步修复：先chown重设属主与组，再find -type d chmod 755确保进入权限，最后find -name "*.php" chmod 644保障读写，同时检查.env.local权限及umask值。
FrankenPHP 启动时提示 “failed to open stream: Permission denied” in cache dir
这基本是 var/cache 目录权限断裂的直接表现，不是 FrankenPHP 本身有问题，而是它启动时尝试写入缓存文件（如 var/cache/dev/App_KernelDevDebugContainer.php）被系统拒绝。Symfony 在 dev 模式下每次启动都会热生成容器类，而 FrankenPHP 是常驻进程，对缓存目录的读写要求比 CLI 更严格。
- 先确认报错路径：错误信息里明确出现的路径（如
var/cache/dev或var/cache/prod）才是关键目标，别只修var/cache根目录 - 检查属主是否匹配 Web 服务器用户：运行
ps aux | grep frankenphp看进程用户（Linux 多为www-data，macOS 多为_www），再用ls -ld var/cache/dev对照属主和组 - 不要用
chmod 777：这会破坏 Symfony 的安全边界，且 FrankenPHP 可能因检测到宽松权限而拒绝启动
修复 var/cache 权限的三步操作顺序不能错
顺序错了会导致 FrankenPHP 启动后反复报错或缓存失效。必须按“属主 → 目录执行位 → 文件读写位”层层推进，中间跳过任何一步都可能白忙活。
- 重设属主与组：
sudo chown -R $USER:www-data var/cache（Linux）或sudo chown -R $USER:staff var/cache（macOS） - 确保所有子目录有
x权限（否则进程无法进入）：find var/cache -type d -exec chmod 755 {} \; - 确保缓存 PHP 文件可读写：
find var/cache -name "*.php" -type f -exec chmod 644 {} \;；若存在.lock文件，也需同样处理
Symfony Dotenv 加载成功但缓存仍失败？检查 .env.local 权限
很多人忽略一点：FrankenPHP 启动时会先加载 .env 和 .env.local，如果后者权限太严（比如 600 且属主不是 Web 用户），虽不报 Dotenv 错误，但后续缓存生成阶段会因环境变量缺失（如 APP_ENV=dev 未生效）而走错路径，最终卡在缓存写入。
- 运行
ls -l .env*，确认.env.local权限是644，且属主/组与var/cache一致 - 临时测试：把
.env.local改名，用纯.env启动 FrankenPHP，看是否还报缓存权限错——若不报了，问题就出在.env.local的权限或内容上 - 避免在
.env.local中写入敏感值后忘记改权限，尤其从 Git 拉取的模板常默认600
FrankenPHP 启动后日志里反复出现 “Cannot write to cache directory”
说明权限修复不彻底，或者有其他进程（比如另一个终端里的 php artisan cache:clear）正在并发修改缓存目录结构，导致 FrankenPHP 的文件锁冲突。这不是配置问题，是状态竞争。
立即学习“PHP免费学习笔记（深入）”；
- 停掉所有相关进程：
killall frankenphp+killall php（Linux）或pkill -f frankenphp（macOS） - 清空缓存并重建：
rm -rf var/cache/*，再手动触发一次php -d variables_order=EGPCS bin/console cache:warmup --env=dev（注意加-d variables_order=EGPCS防止环境变量丢失） - 最后再启动 FrankenPHP：
php artisan octane:start --server=frankenphp --watch，不要加--no-interaction，便于观察首次写入是否成功
var/ 目录本身 umask 是 077，那即使你修好了权限，新生成的缓存文件依然只有属主可读写。启动前加一句 umask 002 再跑命令，能一劳永逸避开这类隐形坑。 
