Doctrine Transport 无法实现数据库解耦，因其与业务表共用PDO连接、事务和锁，导致主库压力大会阻塞消息写入，且无ACK机制易丢消息；真正解耦需独立连接、持久化及ACK支持。
直接用 Doctrine 作为 Transport，无法真正解耦数据库——它只是把消息存进同个库的另一张表，业务表和消息表仍共享连接、事务和锁。
为什么 Doctrine Transport 不等于数据库解耦
Doctrine Transport 本质是把消息写入 symfony_messenger_messages 表，和你的业务表共用同一套 PDO 连接。一旦主库压力大、慢查询多或连接池耗尽，消息写入也会卡住，甚至拖垮整个请求链路。
- 消息发送失败时，
send()会抛出异常，打断当前事务（哪怕你没显式开启） - 消费者进程
messenger:consume启动时仍需连同个数据库，无法隔离故障域 - 没有消息确认机制，消费者崩溃后消息可能丢失（Doctrine 默认不支持重试+ACK）
真正解耦的 Transport 选型要点
要让消息系统和主数据库物理隔离，Transport 必须满足：独立连接、持久化能力、支持 ACK 和重试。Redis 和 AMQP 是主流选择，但行为差异很大：
-
redis://：轻量、低延迟，适合通知类任务；但 Redis 挂掉会导致消息全丢（除非启用 AOF + RDB 持久化并配置合理） -
amqp://（如 RabbitMQ）：强持久化、支持死信队列、消息确认、TTL；适合订单、支付等关键路径 - 避免混用：
doctrine://和redis://不能共用一个 transport 名，否则路由规则会冲突
配置时最容易漏掉的三个硬性条件
即使 DSN 正确，以下三项缺一不可，否则消息根本不会进队列：
- 环境变量
MESSENGER_TRANSPORT_DSN必须在.env中定义且非空，php bin/console debug:messenger能列出 transport 才算生效 -
routing规则必须精确匹配消息类的完整命名空间，比如'App\Message\SendEmailMessage': async，少一个反斜杠或大小写错误都会 fallback 到 sync - 消费者命令必须带 transport 名运行：
php bin/console messenger:consume async --limit=10，不加--limit或拼错async会导致进程空转
解耦不是换一个 DSN 就完事——Transport 是载体，但真正的隔离靠的是连接池分离、故障域切分和运维层面的资源配额。RabbitMQ 部署在独立节点、Redis 单独实例、数据库只读副本不参与消息消费，这些才是落地时最常被跳过的实际步骤。
