订单在下午三点创建，确认邮件晚上才收到。订单流程和邮件发送是两个系统：开启异步发送后，结账只标记待发，Cron/队列稍后生成并交给 SMTP。需要找出延迟发生在“未入队、未消费、生成慢、SMTP 接收慢”哪一步。
以一张订单画时间线
记录订单 created_at、email_sent、相关队列/邮件记录时间、Cron executed/finished、SMTP accepted 与最终投递时间。收件箱显示时间可能经过时区转换，统一用 UTC 比较。
异步配置与 Cron
确认 Sales Emails 的异步选项、对应 Cron job 是否按分钟成功运行。大量 missed/error、一个长任务占住 Group 或系统 crontab 间隔过长，都会造成积压。手工运行 cron 能恢复，只说明入口链路有问题，不是长期方案。
失败邮件会不会阻塞整批
一个无效地址、模板异常或 SMTP 超时若每次从队首重试，可能拖住后续正常邮件。消费者应记录有限重试、错误原因并将永久失败隔离；不能无限重试，也不能静默丢弃。
SMTP 已接收仍延迟
Magento 日志显示 250 accepted 后，延迟发生在邮件服务商、DNS、反垃圾或收件方。用 Message-ID 在服务商日志追踪。不要因为最终投递慢就重复发送，客户会收到多封订单邮件。
模板生成成本
邮件模板中的自定义 block 若查询大量订单项、外部 API 或加载前台页面，会让每封邮件很慢。对批量发送测单封生成时间和 SQL 数，缓存公共数据，但不能跨订单缓存客户内容。
修复后在正常与 SMTP 故障两种场景创建测试订单，观察积压长度、最老消息年龄、重试和恢复速度。邮件应在目标时间内发送，永久失败可见且不会阻塞整条队列。
积压容量怎么估算
计算到达速率、单封平均处理时间和并发消费者数。处理速率低于订单峰值，积压必然增长；只在出事后手工 cron 无法解决。模板生成与 SMTP 发送可拆分监控，决定是优化代码、提高安全并发还是升级邮件服务额度。
队列数据与订单状态
取消订单前尚未发送的确认邮件是否仍应发送，业务要有明确规则。消费者读取旧订单快照可能发出错误状态；发送前重新读取必要字段，同时保持金额与下单时订单快照一致，不能从当前商品价格重算。
多 Store 发件身份
队列处理时若缺少 store emulation，可能使用默认 Store 模板、语言和发件人。记录 store_id、template id、recipient 与 order id，处理后恢复 emulation，避免下一封邮件继承错误范围。
告警与补发
监控最老待发年龄比只看队列长度更有意义。补发工具应按订单/消息唯一键操作，显示原失败原因并要求权限；批量补发前抽样，防止积压恢复后又把同一批发送两次。
建立可操作的积压指标
建议至少记录待发数量、最老消息年龄、每分钟成功数、失败率与 SMTP 响应时间，并按 Store/模板拆分。阈值要与业务承诺对应：订单确认超过十分钟与营销邮件延迟十分钟影响不同。告警中附上最近失败原因和运行节点，值班人员才能直接行动。
恢复时控制发送洪峰
SMTP 恢复后一次性放开全部消费者，可能触发服务商限流并再次失败。按可接受速率逐步提高并发，优先交易邮件，观察 4xx/5xx 与重复率。积压清空后再评估自动扩缩容，而不是把临时高并发永久保留。
