Symfony延迟消息关键在“谁来发”和“什么时候发”，官方推荐Scheduler组件（7.1+）实现定时延迟，或用数据库+Cron模拟，Messenger原生不支持延迟发送。
Symfony 实现延迟消息，关键不在“怎么发”，而在于“谁来发”和“什么时候发”。Messenger 本身不支持原生延迟发送，必须配合 Scheduler 组件（Symfony 7.1+）或借助外部机制（如数据库+Cron）才能真正实现可控的延时触发。
用 Scheduler 组件发定时延迟消息
这是官方推荐、最干净的方式，适用于一次性或周期性任务，比如“注册后24小时发欢迎邮件”“每天凌晨2点生成报表”。
- 确保已安装：
symfony/messenger、symfony/scheduler、symfony/redis-messenger（推荐 Redis 作传输层） - 消息类只需是普通 DTO，无需特殊接口；处理器加
#[AsMessageHandler] - 在处理器类上用
#[AsCronTask('0 0 * * *')]注解定义执行时间（cron 格式），例如：#[AsCronTask('0 0 1 * *')]表示每月1号0点执行 - 也可以用 YAML 配置替代注解，在
config/packages/scheduler.yaml中定义任务 - 注意：Scheduler 触发的是“消息投递”，不是“方法调用”——它会把消息发给 Messenger，再由对应 transport 异步处理
用 Messenger + transport 实现重试型延迟
这不是真正意义上的“定时延迟”，而是失败后的退避重试（如网络超时后 3 秒再试一次）。它不适用于主动规划执行时间的场景。
- 配置
retry_strategy，设置max_retries和delay（单位毫秒） - 仅对投递失败的消息生效，成功发送后不会延迟
- 常见误用：以为配了 retry 就能实现“30分钟后发订单提醒”，实际做不到
用数据库 + Console Command + Cron 模拟延迟
当 Scheduler 不可用、或需要强持久化与人工干预时，这套组合最可靠。适合低频、非实时、需审计的场景，如周报邮件、活动通知。
- 用户触发动作时，只写一条记录到
email_tasks表（含收件人、模板、参数、计划发送时间） - 编写一个
php bin/console app:send-delayed-emails命令，查出due_at <= NOW()且status = 'pending'的任务，逐条发送并更新状态 - 用系统 Cron 每5分钟跑一次该命令：
*/5 * * * * cd /var/www/app && php bin/console app:send-delayed-emails >/dev/null 2>&1 - 优势是可查、可重试、可暂停，缺点是精度受限于 Cron 间隔
常见失效原因与检查清单
很多“延迟没生效”，其实根本没进队列，而是当场同步执行了。
- 路由配置错：
messenger.yaml中routing:的 key 必须是消息类全名（如App\Message\SendWelcomeEmail），不是处理器类名 - transport 显示为
sync：运行php bin/console debug:messenger确认目标消息的 transport 列是否为async - 没启用 Scheduler：检查
kernel.bundles是否包含SchedulerBundle，且环境支持 cron 或 PHP 定时器 - Mailer 直接调用
send()：若在 Messenger 处理器里直接调$mailer->send()，那仍是同步发信——延迟只到处理器被调起那一刻，不等于邮件发出那一刻
