根本原因是symfony未适配常驻内存场景：kernel复用但容器不可重入、db连接未设持久化、日志句柄泄漏、全局变量未重置，导致内存泄漏与连接耗尽。
FrankenPHP 部署 Symfony 时高并发请求卡死，根本原因不是 FrankenPHP 本身扛不住，而是默认以「单进程同步模式」运行，且 Symfony 的容器、事件监听器、数据库连接等组件未适配常驻内存场景——所有资源在请求间不自动释放或复用，导致内存泄漏、连接耗尽、协程挂起失败。
为什么 Symfony 在 FrankenPHP 上会卡死（而非报错）
FrankenPHP 启动后默认使用 php-fpm 兼容模式（即每请求 fork 一个 PHP 实例），但若你启用了 worker 模式（通过 frankenphp:worker 或 Caddyfile 中 php_worker 指令），Symfony 就会持续运行在同一个进程里。这时问题立刻暴露：
- Symfony 的
Kernel实例被复用，但cache:warmup生成的容器未标记为「可重入」，某些服务（如RequestStack、SecurityContext）内部状态残留 - Doctrine DBAL 默认连接未设
pdo::ATTR_PERSISTENT => true，连接在 worker 生命周期内不断新建却未显式关闭，触发 MySQL 的max_connections限制 - 日志通道（如
Monolog\Handler\StreamHandler）在常驻进程中反复打开同一文件句柄，Linux 系统级ulimit -n被快速打满 -
$_SERVER和$_REQUEST全局变量未在每次请求前重置，中间件可能读到上一个请求残留的数据
必须改的 Symfony 配置项（非可选）
以下配置缺一不可，否则 worker 模式下 50+ 并发就大概率卡死：
- 在
config/packages/framework.yaml中强制禁用调试：framework: { debug: false, secret: '%env(APP_SECRET)%' } - 禁用所有开发专用 Bundle（如
SensioLabs\SecurityBundle、Symfony\Bundle\DebugBundle），它们在常驻进程中会累积内存 - 将
doctrine.dbal.connections.default.options显式设为：{ pdo::ATTR_PERSISTENT: true, pdo::ATTR_EMULATE_PREPARES: false } - 替换默认日志 handler：用
RotatingFileHandler替代StreamHandler，并设置max_files: 7防止句柄泄漏 - 在
public/index.php开头加入请求隔离代码：if (extension_loaded('frankenphp')) { $_SERVER = []; $_REQUEST = []; $_GET = []; $_POST = []; }
Caddyfile 中 FrankenPHP worker 模式的正确写法
很多人直接复制 Nginx 的 fastcgi_pass 写法，结果 FrankenPHP 根本没进 worker 模式。关键点在于：worker 必须由 Caddy 主动启动，且需显式声明 PHP 入口和环境变量。
- 错误写法（退化为 FPM 兼容模式）：
php指令单独一行，无参数 - 正确写法（启用真正 worker）：
php_worker { root * /var/www/symfony/public index index.php import php_fastcgi env APP_ENV prod env APP_DEBUG 0 env SYMFONY_DEPRECATIONS_HELPER 0 } - 必须配合
import php_fastcgi—— 它会自动加载 FrankenPHP 内置的 fastcgi 协议支持，否则静态文件能走，PHP 请求直接 502 - 不要加
fastcgi_pass；FrankenPHP 的 worker 不监听外部端口，它和 Caddy 是同一进程内的 libphp 调用
验证是否真正在 worker 模式运行
卡死问题往往源于你以为开了 worker，其实只是 FrankenPHP 在「假装」常驻——它底层仍按请求 fork 新 PHP 实例。最简单验证方式是看进程树和内存增长：
- 执行
ps aux | grep frankenphp，正常应只看到 1–2 个frankenphp进程（主进程 + worker 进程），而不是几十个 - 用
watch -n 1 'pmap $(pgrep frankenphp | head -1) | tail -1'观察 RSS 内存，worker 模式下应缓慢上升后趋于平稳；若每秒暴涨 5–10MB，说明仍在重复加载 Symfony 容器 - 在控制器中临时加一行：
error_log('PID: ' . getmypid() . ', Mem: ' . memory_get_usage());，连续发 10 个请求，如果 PID 不变且内存差值
最关键的忽略点是：FrankenPHP 的 worker 模式不是「开关」，而是需要 Symfony 主动配合的协作模型。你不能只改服务器配置，就指望框架自动适应——它的生命周期管理、资源清理、状态隔离，全得靠你手动补全。漏掉任意一个环节，高并发下不是 500 错误，而是静默卡死，连日志都不写。这种问题在线上最难排查，因为压测工具（如 wrk）只会显示「connection timeout」，而 strace 看到的全是 futex 等待，容易误判为系统层瓶颈。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
