workers.count 设置为 6 较优：4核8gb服务器下，超此值会导致队列堆积、响应延迟上升；需按单worker内存占用（40–90mb）与可用内存计算上限，并关闭 opcache.revalidate_freq=0 和 validate_timestamps=0 以确保容器复用。
workers.count 设置多少才不卡 Symfony 请求
FrankenPHP 的 workers.count 不是“越多越好”，尤其对 Symfony 这类容器重、启动开销大的框架，设高了反而容易触发内存竞争或 PHP 扩展初始化冲突。实测表明，在 4 核 8GB 的生产服务器上，workers.count: 6 是多数 Symfony 项目（含 Doctrine ORM + Redis 缓存）的吞吐拐点：再往上加，frankenphp_busy_threads 增长趋缓，但 frankenphp_queue_depth 开始明显堆积，平均响应时间反而上升。
关键判断依据不是 CPU 核心数，而是 Symfony 应用实际的内存占用和冷启动耗时。你可以用 symfony console debug:container --no-debug 粗略估算容器初始化内存（通常 40–90MB/worker），再结合 php -i | grep memory_limit 确认单 worker 上限。留出至少 2GB 给 FrankenPHP 主进程和 Caddy 模块后，可用内存 ÷ 单 worker 占用 ≈ 可设上限。
为什么 Symfony 在 worker 模式下必须关掉 opcache.revalidate_freq
Symfony 的热重载依赖文件变更检测，而 FrankenPHP 的 worker 模式默认启用 opcache，且 opcache.revalidate_freq 若设为非 0（比如默认的 2），会导致 worker 在每次请求前检查 PHP 文件 mtime —— 这会破坏常驻内存优势，让每次请求都退化成“半冷启动”状态，实测 Laravel/Symfony 接口延迟从 12ms 回升到 45ms+。
必须在 php.ini 或 FrankenPHP 配置的 php.ini_path 中显式覆盖：
opcache.revalidate_freq=0 opcache.validate_timestamps=0
注意：opcache.validate_timestamps=0 必须与 revalidate_freq=0 同时生效，否则 opcache 仍可能在某些条件下强制校验；修改后需重启 FrankenPHP（不是 reload），因为 opcache 配置只在 worker 初始化时读取一次。
如何验证 Symfony worker 是否真正在复用容器
最直接的办法是观察日志和指标是否出现“容器重建痕迹”。Symfony 默认不打容器初始化日志，但你可以加一行临时诊断代码到 public/index.php 开头：
file_put_contents('/tmp/symfony-worker-pid.log', getmypid() . ' @ ' . date('H:i:s') . "\n", FILE_APPEND);
然后压测 100 并发请求，查看 /tmp/symfony-worker-pid.log 中 PID 行数。如果只有 6 行（对应 workers.count: 6），说明请求被均匀分发到了固定 worker；如果出现 30+ 行，说明 worker 在频繁重启或未命中复用逻辑。
更可靠的验证方式是看 Prometheus 指标：
-
frankenphp_total_threads应稳定等于配置值 -
frankenphp_busy_threads在压测中波动但不超过total_threads -
frankenphp_worker_restarts_total（如有暴露）应为 0 或极低频次
一旦发现 worker_restarts_total 持续增长，大概率是某扩展（如 xdebug、blackfire）未兼容常驻模式，或 php.ini 中启用了 register_shutdown_function 类全局清理逻辑。
worker 模式下 Symfony 的 config/cache 清理策略要改
传统 FPM 下，每次请求都会重新生成 var/cache/prod/ 下的容器和路由缓存，所以 cache:clear 只需跑一次。但在 FrankenPHP worker 模式下，已加载的容器不会自动感知磁盘缓存变化 —— 你执行 cache:clear 后，老 worker 仍拿着旧容器运行，新请求可能混用新旧缓存，导致服务提供者找不到、路由 404 等静默错误。
必须配合 FrankenPHP 的热重载机制：
- 确保配置中
features.hot_reload: true - 部署新代码后，用
frankenphp reload（非 restart）触发 worker 平滑滚动更新 - 避免在生产环境用
cache:warmup，它会干扰 worker 初始化流程；改用cache:clear --no-warmup+ 让首个请求自然触发 warmup
这个环节最容易被忽略：很多人清完 cache 就以为万事大吉，结果线上接口开始随机报错，查日志却没有任何异常 —— 实际是新旧缓存版本在多个 worker 间撕裂了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
