frankenphp的reverse_proxy配置仅控制tcp连接层并发，无法干预symfony应用内业务逻辑竞态；真正有效的并发控制必须依赖symfony lock组件配合redisstore驱动，在php代码入口层显式加锁释放。
FrankenPHP 本身不内置接口级并发限制能力，必须靠 Symfony Lock 组件 + 正确 Store 驱动 + 请求入口层协同控制；直接在 FrankenPHP 的 Caddyfile 里配 reverse_proxy 超时或连接数，对 Symfony 内部竞态完全无效。
为什么 FrankenPHP 的 reverse_proxy 并发配置拦不住 Symfony 竞态
FrankenPHP 的 reverse_proxy 层只管 HTTP 连接调度（如 max_conns 10），它无法感知 Symfony 应用内逻辑——比如两个请求同时进 Controller、都通过了 Auth、都走到 $em->persist($order)，这时锁没加或加错，订单照样重复创建。
常见错误现象：Caddy 日志显示连接被限流，但数据库里仍出现重复记录；ab -c 50 压测时失败率低，但业务数据却异常。
- FrankenPHP 不解析 PHP 应用语义，它的并发控制粒度是“TCP 连接”，不是“业务资源”
- Symfony 的 Doctrine ORM、Session、缓存等组件本身无全局互斥，需显式加锁
- 若用
FlockStore，容器重启或挂载卷不一致会导致锁失效——FrankenPHP 常跑在 Docker 中，这点极易踩坑
Lock::acquire() 必须配合 RedisStore 才能在 FrankenPHP 下生效
FrankenPHP 多进程模型（尤其在 worker 模式下）会让 FlockStore 的文件锁跨进程不可见；PdoStore 在高并发写入时易触发死锁或超时。RedisStore 是唯一能保证多 worker 进程间锁状态一致的方案。
实操要点：
- 确认 Redis 实例可被所有 FrankenPHP worker 进程访问（Docker 中需共用 network，不能用
host.docker.internal在 Linux 上失效） - 初始化时显式传参：
new RedisStore($redis, ['retry_interval' => 100, 'timeout' => 3000])，否则默认timeout=0会无限等待 - 锁 key 必须稳定：避免用
__FILE__或动态路由参数拼接，推荐md5('order:create:' . $userId) - 别依赖
__destruct()自动 release——FrankenPHP 的 worker 复用机制可能导致锁残留
CLI 命令和 Web 请求共用锁时的 key 冲突风险
同一个业务逻辑（如“生成月报”）可能既被 Web 请求触发，也被 bin/console app:generate-report 触发。若两者用不同 key（比如 Web 用 report:web:2026-10，CLI 用 report:cli:2026-10），就等于没锁住。
正确做法：
- 定义统一业务标识，如
report:monthly:2026-10，Web 和 CLI 都用这个 key - CLI 命令中显式调
$lock->acquire(true)并设超时，避免卡死影响 Cron 调度 - 检查
LockFactory是否复用同一 RedisStore 实例——不同 Service 容器实例可能各自 new 出新 Store，导致锁隔离 - 用
redis-cli --scan --pattern "symfony_lock:*"手动验证锁是否真实写入 Redis
最常被忽略的是锁的释放时机：FrankenPHP 的请求生命周期比传统 FPM 更复杂，worker 可能复用多次，try/finally 包裹 acquire() 和 release() 是底线；任何异步回调、StreamedResponse 或早期 return 都可能跳过 release，让锁永久滞留。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
