old_sound_rabbit_mq Bundle是Symfony 4.4–6.x对接RabbitMQ最成熟可控方式；需在bundles.php中显式启用，配置须设lazy: false、connection_timeout: 5、read_write_timeout: 10，并用单引号包裹vhost。
直接用 old_sound_rabbit_mq Bundle 是当前 Symfony 项目（4.4–6.x）对接 RabbitMQ 最成熟、最可控的方式。Symfony Messenger 虽然更“现代”，但对 RabbitMQ 的底层控制弱、调试信息少，生产环境出问题时排查成本高。
安装与 Bundle 注册必须同步做
只运行 composer require oldsound/rabbitmq-bundle 不够，你还得显式启用它：
-
config/bundles.php中必须有OldSound\RabbitMqBundle\OldSoundRabbitMqBundle::class => ['all' => true] - 如果项目是 Symfony 7+，注意该 Bundle 官方尚未正式支持 Symfony 7，
lazy: true可能触发服务未初始化错误，建议先降级到 6.4 LTS 或改用 Messenger +symfony/amqp-messenger - 不要混用
php-amqplib/rabbitmq-bundle和oldsound/rabbitmq-bundle—— 后者才是维护活跃的主分支，前者已归档
连接配置里最容易漏掉的三个关键项
光填 host、port、user、password 会在线上环境频繁断连或超时：
-
lazy: false：设为false才会在容器启动时立即建连，否则首次 publish 时才尝试连接，失败就抛异常 -
connection_timeout: 5和read_write_timeout: 10：默认都是 3 秒，内网 OK，跨可用区或 TLS 链路下极易触发AMQPConnectionException -
vhost: '/'必须用单引号包裹，否则 YAML 解析器可能把它当注释处理；若 RabbitMQ 实际 vhost 名含下划线（如app_prod），也务必加引号
生产者配置中 exchange_options 和 queue_options 的区别
很多人误以为两者可互换，其实它们作用阶段完全不同：
-
exchange_options控制消息“怎么发出去”：决定 exchange 名、类型（direct/topic/fanout）、是否durable: true（重启后 exchange 是否保留） -
queue_options只在消费者配置里生效，定义队列本身属性；生产者配置里的queue_options实际被忽略 —— 这是 Bundle 的设计限制，不是你配错了 - 如果你用
type: topic，必须确保 routing key 格式合法（如order.created.us），否则消息会被静默丢弃，日志里只显示NO_ROUTE
消费者类 callback 必须是服务 ID，不是类名
配置里写 callback: App\Consumer\OrderConsumer 是错的，会报 Service "App\Consumer\OrderConsumer" not found：
- callback 值必须是容器中已注册的服务 ID，比如
callback: app.consumer.order - 对应的服务需在
config/services.yaml中显式声明：app.consumer.order: class: App\Consumer\OrderConsumer arguments: ['@logger'] - 该类必须实现
OldSound\RabbitMqBundle\RabbitMq\ConsumerInterface，且execute方法返回ConsumerInterface::MSG_ACK、MSG_REJECT或MSG_REQUEUE—— 返回true或void会导致消息无限重试
真正麻烦的从来不是配置语法，而是 RabbitMQ 自身的语义约束：exchange 是否已存在、queue 是否已绑定、routing key 是否匹配、vhost 权限是否开通——这些都得靠 rabbitmqctl 或管理界面人工核验，Bundle 不会替你创建或修复底层资源。
