用途：把用户不需要等待结果的工作从请求中移出。判断标准是用户是否需要该结果；结果出现在响应中的操作保持同步。异步工作需要有运维负责人与告警机制，否则不应引入队列。
主要能力：Messenger 仅用于离开请求的工作，控制器可直接调用服务，仅在无人等待时 dispatch 消息。默认使用 Doctrine 传输：MESSENGER_TRANSPORT_DSN=doctrine://default?auto_setup=0，队列表由迁移创建，PostgreSQL 与 MySQL 8 支持 FOR UPDATE SKIP LOCKED，可多 worker。消息超过每天数千条时应升级到 Redis 或 AMQP。
三条规则：消息只携带标识符而非实体；处理器必须幂等；处理器只做转换层，解包消息、加载依赖、调用服务。
失败策略：配置 failure_transport 与重试策略（max_retries、delay、multiplier、jitter），消息最终进入 failed 队列并必须触发告警，告警通道不得再进入 Messenger（例如不要用 symfony_mailer）。
优先级队列：按优先级使用不同传输，如 async_high、async、async_low，并用 php bin/console messenger:consume async_high async async_low 消费；Doctrine 接收器不支持 --queues 选项。
邮件与定时：SendEmailMessage 路由到 async，项目有优先级传输后可移至 async_high；TemplatedEmail 由 worker 渲染，上下文必须传标量。定时任务用 #[AsCronTask]，但需要持续运行的 worker。
测试：无需运行 worker，可直接实例化处理器调用；dispatch 需 mock 返回 Envelope，测试时可路由到 in-memory:// 并读取记录的信封。
限制与排查：无 worker 消费时无报错、本地邮件被排队、未运行迁移导致表不存在、部署后处理器运行旧代码、消息被重复处理属正常、实体或代理进入消息或邮件上下文会反序列化失败、缺少 --memory-limit 导致 worker 在约 128 MB 死亡、RecoverableMessageHandlingException 默认强制重试等问题需按资料处理。详细配置见 references/messenger.md、references/mailer.md、references/scheduler.md。