客户在购物车输入优惠码后看到折扣，进入结账或选择配送方式后折扣消失。这个现象不一定是前端丢了 coupon code，很多购物车价格规则要等地址、运费、客户组和支付信息完整后重新验证；重算后条件不满足，Magento 会合法地移除折扣。

确认 coupon code 是否还在 Quote 上

先在结账接口响应和数据库中查看 quote：

SELECT entity_id, store_id, customer_group_id, coupon_code,
       subtotal, base_subtotal, grand_total, updated_at
FROM quote
WHERE entity_id = 12345;

coupon_code 仍在但 discount_amount 变为 0，说明规则重新计算后未命中；coupon_code 本身被清空，则检查前端调用、扩展插件或规则校验返回。不要直接修改 quote 表恢复优惠码，下一次 collect totals 仍会覆盖。

地址条件只有在结账时才完整

规则可能限制国家、地区、邮编、配送方式或运费金额。购物车阶段使用默认地址估算，客户在结账输入真实地址后条件变化，折扣自然失效。Free Shipping、Payment Method 条件也可能在选择相应步骤后才确定。

检查规则 Conditions 与 Actions 的区别：Conditions 决定整个购物车是否符合，Actions 下面的条件决定哪些商品行参与折扣。常见错误是把 SKU、分类或属性条件放在错误区域，导致购物车预览与最终行折扣看起来不一致。

客户登录会改变客户组和历史次数

访客在购物车使用成功，登录后进入结账失效，要检查规则允许的 Customer Groups、每位客户使用次数和全局使用次数。使用相同邮箱的历史订单、取消订单处理和异步更新都可能影响计数。规则的 From/To 日期还依赖商店时区。

其他规则和 Stop Further Rules Processing

结账时命中另一条优先级更高的规则，并启用“停止后续规则处理”，会让原优惠不再应用。按优先级检查所有当前有效规则，而不是只看用户输入的那一条。多个优惠能否叠加必须由业务规则明确决定。

前端显示也可能滞后

接口 totals 中已有折扣而页面没有显示，检查 checkout totals segment、自定义 total renderer 和 customer-data。一步结账扩展可能没有在地址或配送方式变化后正确重新加载 totals。以 REST/GraphQL 返回和 quote totals 为证据，区分计算错误与显示错误。

验证时构造边界用例：访客与登录客户、允许与不允许地区、最低金额前后、含特价商品、切换配送方式和支付方式。每次观察 coupon_code、discount segment 和 grand total，才能确认规则在结账全过程稳定。