Symfony API回调场景下请求阻塞引发504错误问题求助

这个阻塞和Symfony框架业务逻辑无关，是典型的开发环境服务配置导致的请求死锁：

• 本地默认启动的Symfony开发服务器（执行symfony server:start启动）、PHP内置测试服务器（php -S启动）默认仅启动1个工作进程，同一时间只能串行处理单个请求，后续请求全部进入队列等待。
• 当前业务链路形成了循环等待：创建订阅的请求A占住唯一工作进程，同步调用教师侧支付接口后就挂起等待回调结果；教师侧发来的回调请求B进了队列但拿不到工作进程无法执行，请求A等不到回调就一直卡着，直到504超时把请求A掐断释放进程，B才会被执行，完全走不通流程。
• 若两个路由都默认开启了Session，PHP的文件Session锁也会导致同SessionID的请求强制串行排队，但这个场景下绝大多数情况都是单进程服务器的问题。

按实现成本从低到高排列，按需选择即可：

• 方案1：调整开发服务器启动参数（最快见效，适合课程项目快速调试）
  启动Symfony本地服务器时指定多工作进程数，打破单进程串行限制：

  symfony server:start --workers=4
  

  启动后服务可同时处理4个并发请求，请求A占用1个进程等待时，回调请求B可以用剩余进程正常执行，不会卡死。进程数不要设置得超过你机器的CPU逻辑核心数，避免频繁进程切换拖慢性能。
• 方案2：重构支付链路为异步逻辑（标准实现，生产环境通用）
  不要在创建订阅的请求中同步等待支付回调完成再返回响应，正确的支付流程应该是：
  1. 创建订阅的请求进入后，先生成本地待支付订阅记录，状态标记为待支付
  2. 直接给前端返回支付已发起的响应，立刻释放当前占用的工作进程
  3. 调用支付接口的逻辑丢给后台异步任务执行（Symfony可以直接用内置Messenger组件实现），不需要阻塞当前请求等待结果
  4. 支付侧的回调请求进入时，直接校验参数、更新订阅状态、写入交易记录即可
  5. 前端通过短轮询或者WebSocket获取最终支付状态
     这种写法从逻辑上避免了循环等待，不管开发还是生产环境都不会出现同类阻塞问题。
• 方案3：换用支持并发的本地运行环境
  如果不想改启动参数、也暂时不想重构逻辑，可以直接把本地运行环境换成Nginx + PHP-FPM的模式，PHP-FPM默认会启动多个工作进程处理并发请求，天然不会出现单请求阻塞全服务的问题。

注意：不要在生产环境使用Symfony/PHP内置的单进程开发服务器，生产环境必须用Nginx/Apache + PHP-FPM的部署架构，这类架构默认就支持并发请求处理，不会触发本次遇到的阻塞问题。

内容的提问来源于stack exchange，提问作者Quillian Chardon