客户收到的订单确认邮件总价是 1,020 元，后台订单却显示 1,000 元。遇到这种问题，不应先修改邮件模板里的数字，因为订单邮件通常读取订单实体的金额快照；真正差异可能来自币种字段、税费展示配置、折扣分摊，或邮件发送时间早于后续调整。

先比较同一组金额字段

SELECT entity_id, increment_id, order_currency_code, base_currency_code,
       subtotal, discount_amount, shipping_amount, tax_amount, grand_total,
       base_subtotal, base_discount_amount, base_shipping_amount,
       base_tax_amount, base_grand_total
FROM sales_order
WHERE increment_id = '000000123';

后台可能按订单货币显示 grand_total，自定义邮件却错误使用 base_grand_total。多币种站点汇率不是 1 时，两者当然不同。还要确认邮件中的数字是小计、应付金额还是已付款金额，名称翻译错误也会造成误解。

模板不应该自行重新计算

标准 totals block 会按订单 totals 顺序渲染小计、折扣、运费、税费和总计。自定义模板如果用商品行价格相加再加运费，容易漏掉购物车规则、Weee、礼品卡、store credit、舍入差额或含税价格。邮件应展示订单已经保存的金额，而不是在模板层复制一套计算器。

检查主题覆盖的邮件模板和 layout handle，特别是自定义 block 是否调用 getBaseGrandTotal()、对负数折扣又减一次，或者把格式化后的字符串当数字运算。临时切回标准模板可用于对比，但不要直接在生产环境丢弃品牌模板。

税费显示配置会让行项目看起来对不上

后台 Stores → Configuration → Sales → Tax 中，订单、发票、贷项通知与邮件有独立显示配置。行价格含税、小计不含税时，读者手算可能得不到邮件总计，但底层订单金额仍正确。应把邮件每一项的含税口径标清，而不是调整 grand total 去迎合手算。

确认邮件发送时机

订单创建后，支付扩展可能更新运费、手续费或附加费；如果邮件在更新前入队，邮件使用的是当时序列化或加载的订单状态。检查异步邮件队列、支付回调和观察者执行顺序。重复发送同一订单后金额正确，通常说明第一次发送过早。

验证不能只看一封旧邮件

在测试环境建立含税、折扣、运费和外币的订单，对照数据库、后台、邮件和支付请求四处金额。模板修复后新建订单，不能用已经生成的旧邮件缓存判断。若支付平台扣款金额也不同，优先按交易事故处理；若仅展示不同，则修复模板与发送时机，并保留订单原始金额审计。还要各做一次部分开票和退款，确认后续邮件没有把订单总额、发票总额与退款金额混为一谈。