Doctrine Transport 不能与业务事务一致，因其消息写入使用独立事务，与业务 EntityManager 无关联；强行共用会导致业务回滚时消息仍留存，破坏原子性。
Messenger 的数据库 Transport 本身不提供事务一致性保障，强行套用会导致数据错乱或丢失——它只负责消息投递，不参与业务事务边界。
为什么 Doctrine Transport 不能和业务事务一起提交
Doctrine Transport（如 doctrine://default）把消息写进数据库表（比如 messenger_messages），看似“同库”，但实际执行时机和事务控制权完全分离：
- 业务代码中调用
$bus->dispatch(new MyMessage())时，消息只是被写入messenger_messages表，但该写入操作由 Messenger 自己管理事务，不是你当前正在使用的EntityManager事务的一部分 - 如果你在同一个事务里先更新用户余额、再 dispatch 消息，一旦后续业务逻辑抛异常并 rollback，用户余额会回滚，但消息已落库且不会自动撤回
- Doctrine Transport 的“事务”是它自己开的独立事务，与你的业务上下文无感知、无嵌套、不可传播
如何让消息发送真正跟随业务事务（即“发消息失败则整个事务失败”）
必须放弃默认的异步 Transport 路由方式，改用同步 + 手动事务控制。关键点在于：不走 Messenger 的自动 dispatch 流程，而是把消息当作普通业务数据，在你自己的事务中显式插入。
- 禁用
routing配置中对目标消息的异步路由，例如移除'App\Message\UpdateInventory': async - 在业务服务中，用
EntityManager直接向messenger_messages表插入记录（需手动序列化消息、设置available_at等字段） - 确保这条 INSERT 和你的业务更新语句在同一个
EntityManager->flush()+Transaction::commit()块内 - 消费者端仍用标准
php bin/console messenger:consume拉取处理，只是投递阶段变成了强一致
示例伪代码：
$em->transactional(function(EntityManagerInterface $em) use ($user, $message) {
$user->setBalance($user->getBalance() - 100);
$em->persist($user);
<pre class="brush:php;toolbar:false;">// 手动写入消息表，复用 Doctrine 连接和事务
$stmt = $em->getConnection()->prepare('INSERT INTO messenger_messages (body, headers, queue_name, created_at, available_at) VALUES (?, ?, ?, ?, ?)');
$stmt->bindValue(1, serialize($message));
$stmt->bindValue(2, json_encode([]));
$stmt->bindValue(3, 'async');
$stmt->bindValue(4, new \DateTimeImmutable());
$stmt->bindValue(5, new \DateTimeImmutable());
$stmt->executeStatement();
});
Doctrine Transport 在高并发下容易丢消息的真相
这不是 Bug，而是设计使然：它的“可用时间”（available_at）依赖数据库查询排序，且无行级锁保护消费过程。
- 多个 worker 同时执行
SELECT ... FOR UPDATE时，若未正确加锁或隔离级别不足（如 MySQL 的 READ COMMITTED），可能重复消费同一条消息 - 消息表没有唯一约束来防重入，如果消费者崩溃后重启，可能再次拉取已处理但未标记为
delivered_at的消息 - 更严重的是，
doctrineTransport 默认不启用visibility_timeout类机制，无法防止“幽灵消费”
真实踩坑场景：电商秒杀中，同一库存扣减消息被两个 worker 同时捞到，导致超卖。这不是网络问题，是 Transport 层缺乏幂等性基础设施。
替代方案比硬刚 Doctrine Transport 更可靠
除非你有极强的 DBA 支持且能接受定制化维护，否则应优先考虑外部队列。它们天然支持事务外延、死信、重试、可见性超时等能力：
-
amqp://（RabbitMQ）：通过 publisher confirms + tx.select 实现发送端事务确认；消费者端可设prefetch_count=1防重复 -
redis://（Redis Streams）：利用XADD+XGROUP+XACK构建带 ACK 机制的消费模型，天然支持失败重投 - 若必须用数据库，推荐自建轻量表 +
SELECT ... FOR UPDATE SKIP LOCKED（PostgreSQL / MySQL 8.0+），绕过 Messenger 内置 Transport
复杂点在于：事务一致性从来不是 Transport 单方面的事，它取决于你如何定义“一致”——是消息必达？是业务状态与消息严格同步？还是最终一致即可？选型前得先回答这个问题，而不是默认 Doctrine 就能兜底。
