后台已更新订单邮件模板，测试邮件正常，但客户继续收到旧版本。异步邮件可能在入队时保存模板与变量快照，旧消息不会因后来编辑自动重写；也可能目标 Store 仍引用另一模板 ID。

固定复现条件

记录一封旧内容邮件的订单、入队时间、发送时间、Store、模板标识和部署版本。比较修改前已排队与修改后新建订单。

php bin/magento config:show sales_email/general/async_sending
php bin/magento config:show sales_email/order/template --scope=stores --scope-code=store_code
SELECT template_id,template_code,added_at,modified_at FROM core_email_template ORDER BY modified_at DESC LIMIT 20;
SELECT message_id,topic_name,status,updated_at FROM queue_message_status ORDER BY updated_at DESC LIMIT 30;
ps -ef | grep -E '[c]ron:run|[q]ueue:consumers:start'

根据证据定位

只有修改前消息旧是预期快照行为；新订单也旧，查 Store Scope 与模板 ID；重启长进程后恢复说明 Consumer 缓存或旧代码；后台预览正确但邮件错误，还要检查 area/store 模拟。

修复与回滚

在正确 Store 保存并选择模板，修复队列消费者的 Store 上下文。对已排队邮件按业务与合规要求决定继续、取消或重新生成，不能直接改消息正文造成审计不一致。

验收

修改模板后创建新订单，主题、正文与变量均为新版本；旧队列处理策略可追踪，两个 Store 不串模板，重试不会重复发送。

生产环境操作前的检查

处理“Magento 2 异步邮件仍发送旧模板内容”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层证据通过标准
入口 URL、状态码、请求 ID、节点 路由与协议一致
应用 异常堆栈、模块、作用域 无新异常且可重复
数据 主键、时间、关联行数 关系完整无重复副作用
业务 正常、失败与重试路径 最终状态一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。