多地址结账一次提交会拆成多张订单。某个地址的支付或库存校验失败时，前面的订单可能已经提交，页面却只显示总失败。处理这类问题要先找已生成的increment_id，不能让客户整单重试。

问题不在表面

先用一个真实失败样本复现，不要一上来全量重建。把请求、实体ID和时间记下来，后面的SQL与日志才能对得上。

几条命令足够定位

  • 按quote_id查询sales_order，确认成功了几张。
  • 结合checkout_submit_all_after前后的日志，确定失败发生在哪个地址。
mysql -e "SELECT increment_id,status,shipping_address_id,grand_total FROM sales_order WHERE quote_id=12345 ORDER BY entity_id;"
grep -R "12345" var/log | tail -n 100
mysql -e "SELECT entity_id,address_id,qty FROM quote_address_item WHERE quote_id=12345;"

这里的重点不是把报错暂时消掉，而是让同一操作再执行一次仍保持幂等；因此修复后一定要做第二次重复执行测试。

改动落在哪里

自定义校验尽量放在创建第一张订单之前，对所有地址先做库存、配送、支付可用性预检。外部调用使用幂等键。已有部分订单时，给客服展示已成功订单号与失败地址，按业务决定补单或取消，禁止直接重新激活原quote并全量提交。

实施时的顺序

  • 先在单个SKU、单个订单或单个Store验证。
  • 保留可回退的旧配置，不覆盖原始证据。
  • 需要批量处理时分批提交并输出成功/失败清单。

验收清单

  • 故意让一个地址失败时不会重复前面订单
  • 日志能关联quote、address和order
  • 库存预留数量与成功订单一致
  • 客户收到的邮件数量正确

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

不要这样处理

不要用一个跨外部支付的超大数据库事务追求“全有或全无”，锁和不可回滚副作用会更难处理。