symfony messenger 中消息未异步投递，通常是因为路由配置错误地指定了处理器类而非消息类；正确做法是将消息类（如 snowplowmessage）映射到异步传输，而非其处理器类。
在 Symfony Messenger 架构中，“路由（routing）”的本质是定义哪些消息类应通过哪个传输（transport）发送，而非指定由哪个处理器（handler）处理。这是一个关键设计原则：路由发生在消息被 dispatch 的第一时间，即在消息进入总线后、尚未被任何 handler 处理前，就已根据消息的 FQCN（完全限定类名）决定其投递目标——是直接同步执行，还是序列化后发送至 AMQP/RabbitMQ 等异步传输。
你当前的配置：
routing:
'Name\Space\MessageHandler\SnowplowNotificationHandler': async_medium是无效的，因为 Messenger 完全忽略处理器类名在 routing 中的出现。它只识别消息类（例如 Name\Space\Message\SnowplowMessage）。当路由表中找不到匹配的消息类时，Messenger 会回退至默认行为：同步执行（即直接调用 handler 的 __invoke() 方法），这正是你观察到“消息未入队、立即执行”的根本原因。
✅ 正确配置应明确指向消息类：
messenger:
transports:
async_medium:
dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
retry_strategy:
max_retries: 3
delay: 1000
routing:
# ✅ 正确：路由消息类到异步传输
'Name\Space\Message\SnowplowMessage': async_medium
# ? 可选：为其他消息设置不同策略（如失败重试、同步处理）
'App\Message\NotificationMessage': sync
'App\Message\HeavyTaskMessage': async_medium配置修正后，请务必执行以下验证步骤：
-
清除缓存（开发环境）：
php bin/console cache:clear
-
确认路由生效：
php bin/console debug:messenger
输出中应明确显示：
Name\Space\Message\SnowplowMessage → async_medium
-
触发消息发送并检查队列（以 RabbitMQ 为例）：
// 在控制器或服务中 $bus->dispatch(new SnowplowMessage($payload));
此时不应看到 handler 被立即调用；应通过 rabbitmqctl list_queues 或管理界面确认 async_medium 对应队列中出现新消息。
⚠️ 注意事项：
- 消息类必须实现 Symfony\Component\Messenger\Envelope 兼容接口（通常只需继承 Symfony\Component\Messenger\Message 或保持为普通 PHP 类即可，Messenger 会自动封装）；
- 若使用 @AsMessageHandler 注解或自动注册，确保 SnowplowNotificationHandler 的 __invoke() 方法签名接收的是 SnowplowMessage 实例，而非其他类型；
- 同步/异步行为与 handler 是否声明为 async 无关——handler 本身永远是同步调用的；异步性由消息投递阶段（transport）保证；
- 若需对同一消息类型实现条件异步（如基于环境或负载），应通过自定义 SendersLocatorInterface 或中间件实现，而非在 routing 中混用 handler 名。
总结：Messenger 的 routing 是消息分发的“交通管制”，它只认消息的类型（class），不认处理者（handler）。牢记这一原则，可避免 90% 的异步失效问题。
