不会。FrankenPHP 仅替换 PHP 运行时和 Web 服务器，不改变 Symfony 的路由与访问控制逻辑，所有请求仍经 public/index.php 入口，config/、src/、var/ 等目录受 PHP 权限和 Caddy root 配置保护；若私有路径被意外访问，主因是部署时错误将项目根目录设为 Web 根而非 public/ 子目录。
Symfony 项目中 public/ 目录外的文件默认不可访问，FrankenPHP 会绕过这个限制吗？
不会。FrankenPHP 本身不修改 Symfony 的路由和访问控制逻辑，它只是更高效的 PHP 运行时。所有请求仍经由 public/index.php 入口，Symfony 的 Kernel 和 Request 生命周期完全保留。也就是说，config/、src/、var/ 等目录依然受 PHP 文件权限和 Web 服务器路径限制保护。
为什么用 FrankenPHP 后，某些私有路径突然能被直接访问了？
常见原因是 Docker 或二进制部署时错误地将整个项目根目录挂载为 Web 根，而非仅 public/ 子目录。比如：
- 在
docker run中用了-v $(pwd):/app，但没配 Caddy 的root指向/app/public - 用 FrankenPHP standalone 二进制时，执行
frankenphp php-server --document-root .（当前目录是项目根），而非--document-root public - Dockerfile 中写的是
COPY . /app，但没在 Caddy 配置里显式限定root /app/public
这些操作会让 Caddy（FrankenPHP 底层）直接服务整个项目目录，暴露 composer.json、.env、src/Controller/ 等敏感路径。
如何确保 Symfony 私有文件不被外部访问？
关键不是改 Symfony，而是约束 FrankenPHP 的 Web 根和 Caddy 行为：
立即学习“PHP免费学习笔记（深入）”；
- 始终用
--document-root public启动 standalone 服务：frankenphp php-server --document-root public - 在 Docker 环境中，必须在 Caddyfile 或环境变量中明确指定
root /app/public；官方镜像默认已设好，但自定义配置时容易覆盖 - 验证是否生效：访问
http://localhost/config/services.yaml应返回 404（Caddy 层拦截），而不是 403 或原始文件内容 - 对
var/和config/目录加额外防护：在Caddyfile中添加handle_path /config/* { respond 404 }类似规则（仅当需要多层防御时）
APP_ENV=prod 能防止私有文件泄露吗？
不能。环境变量只影响 Symfony 的行为（如是否显示错误详情、是否启用调试工具栏），不影响 Web 服务器能否读取并返回文件。即使 APP_ENV=prod，只要 Web 根配置错误，src/ 下的 PHP 文件仍可能被当作静态文件直接输出（尤其是未匹配到 PHP 处理器时）。真正起作用的是 Caddy 的 php 指令范围和 root 路径限制——这两者决定了哪些路径交由 PHP 执行、哪些被拒之门外。
