dispatch后消息直接同步执行是因为路由配置错误，routing键应为消息类名（如App\Message\SendEmailNotification）而非处理器类名，需检查messenger.yaml配置、运行debug:messenger确认transport为async，并确保类名拼写正确和自动加载正常。
为什么 dispatch 后消息没进队列，反而直接同步执行了？
这是最常遇到的“异步失效”问题——你以为发到了 RabbitMQ 或 Redis，实际 SendEmailNotification 一 dispatch 就当场调用处理器，HTTP 请求卡住几秒才返回。
根本原因几乎总是路由配置错位：你把处理器类名写进了 routing，而不是消息类名。
-
routing的键必须是App\Message\SendEmailNotification（你new出来的那个类），不是App\MessageHandler\SendEmailNotificationHandler - 检查
config/packages/messenger.yaml，确认没有类似'App\MessageHandler\...': async这种错误映射 - 运行
php bin/console debug:messenger，看输出里transport列是否明确写着async；为空或显示sync就说明没命中路由 - 类名拼错、命名空间没自动加载也会导致路由失效，执行
composer dump-autoload -o再试
Redis 和 AMQP（如 RabbitMQ）传输选哪个？
别被“高并发”“微服务”这些词带偏，先看你的部署环境和运维能力。
- 本地开发或小项目用
redis://localhost:6379/messages最省事：无需额外服务，启动快，延迟低，适合邮件、日志、简单通知 - 生产环境且已有 RabbitMQ 团队支持？优先选 AMQP：
amqp://guest:guest@localhost:5672/%2f/messages，它有更精细的重试、死信、优先级控制，故障隔离更强 - 别用 Doctrine 传输跑高吞吐任务：数据库锁+慢查询会拖垮主业务，只适合极低频、临时过渡场景
- 注意 DSN 中的 path 部分（如
/messages）：RabbitMQ 里对应 exchange 名，Redis 里是 list key 名，不一致会导致消息写入/读取错位
消息类里能放 Doctrine 实体吗？
不能。这是导致消费者崩溃、序列化失败、数据不一致的高频雷区。
-
SnowplowMessage里如果存了$userEntity或$orderRepository，反序列化时会报Unserialization of 'Doctrine\ORM\Proxy\__CG__...' is not allowed - 正确做法：只传 ID、字符串、数字、数组等可安全序列化的原始数据，例如
['order_id' => 123, 'email' => 'u@example.com'] - 处理器内再通过 ID 查库：
$order = $this->orderRepository->find($message->getOrderId())，保证上下文干净、解耦清晰 - 闭包、
resource、stdClass实例同理，一律禁止出现在消息对象属性中
怎么让一个消息延迟 5 分钟再处理？
别改配置文件，也别手写 sleep —— Messenger 提供了标准 Stamp 机制，干净又可靠。
- 发送时加
DelayStamp：$bus->dispatch(new SendEmailNotification('u@example.com'), [new DelayStamp(300000)])（单位毫秒） - AMQP 传输下，延迟靠 RabbitMQ 的 TTL + 死信交换机实现；Redis 下则依赖
BRPOPLPUSH轮询或ZSET排序，性能略低但够用 - 避免在 Handler 里手动
sleep(300)：会阻塞整个 worker 进程，其他消息全卡住 - 延迟时间超过 49 天（
2^32-1毫秒）在某些传输上会溢出，超长定时任务建议改用数据库轮询或 Cron 触发
异步不是加个 dispatch 就完事，关键在消息设计是否可序列化、路由是否精准命中、传输是否匹配运维能力——这三处任一出错，都会让“异步”变成“假异步”，还更难排查。
