Symfony Messenger配置需明确定义transports和routing，DSN连接后端（如Redis、Doctrine、AMQP），路由按消息类名匹配传输器，环境变量管理DSN，通过debug:messenger等命令验证生效。
Symfony 消息传输（Messenger）配置核心在于定义传输器（transport）并把消息路由到它，不是装完组件就自动生效——得明确告诉框架“哪类消息走哪条路”。关键在 messenger.yaml 的 transports 和 routing 两块，缺一不可。
基础传输配置：选对 DSN，连上后端
传输器本质是连接具体消息队列的通道。Symfony 支持多种后端，DSN 格式决定用什么驱动：
-
Doctrine（数据库表模拟队列）：适合开发或低流量场景，DSN 形如
doctrine://default，需确保 Doctrine 已配置且表已迁移（php bin/console doctrine:migrations:migrate） -
Redis：高性能首选，DSN 如
redis://localhost:6379/messages，推荐加?serializer=php或symfony_serializer避免序列化兼容问题 -
AMQP（RabbitMQ）：企业级可靠传输，DSN 类似
amqp://guest:guest@localhost:5672/%2F/messages，注意 vhost 要 URL 编码 -
自定义或云服务：只要实现
TransportInterface，就能接入 Kafka、阿里云 MNS 等私有系统
消息路由：让消息找到正确的传输器
光有传输器没用，还得指定哪些消息走哪个 transport。路由规则写在 routing 下，按类名全限定名匹配：
- 单条消息绑定：
'App\Message\PaymentProcessed': async表示该类消息只走async传输 - 通配符支持：
'App\Message\*': async匹配整个命名空间下所有消息 - 多路由可叠加：
'App\Message\AlertMessage': [async, urgent]（需对应多个已定义 transport） - 不匹配的消息默认同步执行（不进队列），容易阻塞请求，务必检查路由是否覆盖全部业务消息类
环境变量与多环境适配
不要把 DSN 写死在 YAML 里。统一用环境变量管理：
- 在
.env中设：MESSENGER_TRANSPORT_DSN="redis://127.0.0.1:6379/messages" - YAML 中引用：
async: '%env(MESSENGER_TRANSPORT_DSN)%' - 不同环境可设不同变量，例如测试用
doctrine://default，生产切 Redis 或 RabbitMQ - 敏感信息如密码、密钥绝不硬编码，环境变量 + .env.local 分离更安全
验证与调试：确认配置真起作用
配完别急着发消息，先做三步验证：
- 运行
php bin/console debug:messenger：列出所有 transport、路由映射和中间件，确认你的消息类出现在对应 transport 下 - 发一条测试消息，然后查 transport 对应的底层存储（如 Redis 的
messageslist、Doctrine 的messenger_messages表），看是否入队 - 手动触发消费：
php bin/console messenger:consume async --limit=1，观察处理器是否执行、日志是否输出
