需在 messenger.yaml 中配置 async transport 并路由消息类，如 async: 'doctrine://default?queue_name=async' 和 routing: 'App\Message\SendEmail': async；消息类须可序列化，避免闭包或未声明属性；消费时应加 --limit、--failure-limit 等参数防死循环；调试可查 messenger_messages 表状态或用 messenger:failed 命令。
如何配置 Symfony Messenger 基础传输（如 async transport）
默认安装后 Messenger 只走同步处理，必须显式配置 transport 才能异步执行。常见错误是写了 dispatch($message) 却发现消息立刻被 handle，毫无延迟——根本没启用 transport。
在 config/packages/messenger.yaml 中至少定义一个 async transport，并标记为 default 或绑定到对应 message 类：
framework:
messenger:
transports:
async: 'doctrine://default?queue_name=async'
# 或使用 amqp / redis：'amqp://localhost/%2F/messages'
routing:
'App\Message\SendEmail': async注意：doctrine transport 依赖 doctrine/doctrine-bundle，且需运行 php bin/console doctrine:migrations:generate（它会自动创建 messenger_messages 表）；若表不存在，dispatch 不报错但消息永远卡住。
为什么 dispatch 后消息没进队列？检查 serializer 和 message 类约束
消息类必须可序列化，否则 Doctrine transport 写入时静默失败（日志里可能只显示 Failed to serialize message）。常见坑包括：
立即学习“PHP免费学习笔记（深入）”；
- 含闭包、资源句柄（如
resource、Closure）或未声明的私有属性 - 用了 PHP 8.2+ 的只读类（
readonly class），但未加[Serializable]属性（PHP 8.3+ 支持，旧版不兼容） - 自定义了
__serialize()但漏掉某个字段，反序列化后 handle 时抛TypeError
建议做法：消息类保持简单，只用 public 属性或标准 getter/setter；必要时加 #[\Symfony\Component\Messenger\Attribute\AsMessage] 显式标注（非必需但利于 IDE 识别）。
如何手动触发消费（consume）并避免死循环或重复处理
php bin/console messenger:consume async 是开发常用命令，但直接在生产环境裸跑会出问题：
- 没加
--limit=50或--time-limit=3600，进程可能无限运行导致内存泄漏 - 没配
--failure-limit=3，单条消息反复失败会阻塞整个队列 - 没设
--sleep-on-empty=3，空队列时高频轮询 DB，徒增负载
生产部署应配合进程管理器（如 supervisor）启动守护进程，并确保 failure_transport 已配置（例如指向 failed transport），否则失败消息直接丢弃。另外，Doctrine transport 默认不支持并发消费（同一 connection 下多 worker 会抢锁），真要并行得换 redis 或 amqp。
如何调试消息生命周期：从 dispatch 到 failed
最实用的调试方式不是看日志，而是查数据库表（Doctrine transport）或 Redis key（redis transport）。比如执行：
php bin/console messenger:failed:show
能列出所有失败消息及原始异常；而 messenger:failed:retry 可重试指定 ID。更底层的验证方法是直接查 messenger_messages 表：
-
available_at IS NOT NULL AND delivered_at IS NULL→ 等待投递 -
delivered_at IS NOT NULL AND acknowledged_at IS NULL→ 正在处理中（可能卡住） -
acknowledged_at IS NOT NULL→ 成功完成
别忽略 redelivered_count 字段——它暴露了消息是否被反复重发，这往往是 handler 里没 catch 异常或事务没正确提交的信号。
