frankenphp + messenger 易重复消费，因常驻进程导致消息未及时ack、重启时未处理未完成消息、doctrine事务锁失效；须配置failure_transport、禁用auto_setup和lazy模式、worker启动加--no-reset参数，并分离http与consumer进程。
FrankenPHP 本身不管理 Symfony Messenger 的消息消费生命周期，重复消费问题几乎总是来自 symfony/messenger 的传输层配置与 worker 模式运行方式的冲突，而不是 FrankenPHP 的 bug。
为什么 FrankenPHP + Messenger 容易重复消费
FrankenPHP 的 worker 模式会让 PHP 进程常驻内存，而 Symfony Messenger 默认的 doctrine 或 redis 传输在「接收 → 处理 → 标记为已处理」这个流程中，依赖进程退出时的自动确认（ack）或超时机制。但常驻进程不会退出，导致：
- 消息被取出来后未及时 ack，broker 认为它卡住了，重新投递
- 进程重启（比如热更新、配置重载）时未正确处理未完成消息，触发重复拉取
- doctrine 传输使用数据库事务 + SELECT FOR UPDATE，但在长生命周期进程中，连接可能被回收或事务未提交，锁失效
必须检查的 transport 配置项
以下配置直接影响是否重复，不是可选项：
-
failure_transport必须显式设置，否则失败消息会被丢弃或重入死循环 -
retry_strategy的max_retries和delay要和你的业务容忍度匹配；FrankenPHP 下默认的指数退避可能让重试间隔过长，掩盖问题 - 使用
doctrine传输时，transport_options中必须设"auto_setup" => false，否则每次 worker 启动都尝试建表/改 schema，引发竞争 - Redis 传输需禁用
lazy模式："lazy" => false，否则连接复用可能导致 ACK 丢失
worker 启动命令必须带 --no-reset
如果你用 php bin/console messenger:consume 在 FrankenPHP 环境里手动启 worker（比如通过 supervisor），必须加参数：
php bin/console messenger:consume async --limit=100 --time-limit=3600 --no-reset
原因：--no-reset 禁用每次消费后重置容器和服务，避免 Doctrine EntityManager、Redis 连接等被销毁重建——这正是重复消费的温床。FrankenPHP 的常驻模型要求服务实例稳定存活，reset 会破坏状态一致性。
真正安全的生产方案是分离 consumer 进程
别让 Messenger consumer 和 HTTP worker 共享同一个 FrankenPHP 进程。最稳的做法是：
- HTTP 请求走 FrankenPHP（启用 worker 模式）
- Messenger 消费走独立 CLI 进程，用 supervisord 或 systemd 管理，命令里带 --no-reset 和明确的 --time-limit
- 两者共用同一套 doctrine 或 redis 配置，但完全隔离生命周期
这样既发挥 FrankenPHP 的 HTTP 性能优势，又避开它对 long-running CLI consumer 的隐性干扰。
重复消费往往在压测或日志不全时才暴露，建议上线前用 doctrine:messenger:setup-transports 清理残留表，并在 consumer 日志里加 message_id 和 redelivered 字段输出，才能快速定位是 transport 重发还是代码逻辑误触发。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
