页面上的转圈很有迷惑性，看起来像Carrier接口超时，实际上这次Network里 shipping-information 请求不到一秒就返回500。自定义邮编校验器抛出了普通Exception，REST错误体又被前端Mixin吞掉，导致loading状态没有在fail分支复位。要同时修后端异常边界和前端状态，单纯把超时时间调大没用。

先从浏览器Network确定卡在哪个请求

  • estimate-shipping-methods：购物车页或地址变化时预估运费
  • shipping-information：结账提交地址和所选配送方式
  • payment-information：已经越过运费，卡在支付阶段

把失败请求的Request Payload保存下来，重点看countryId、regionId、regionCode、postcode以及street数组。用相同载荷直接请求接口，比在页面里反复点更容易重现。

curl -i 'https://example.com/rest/default/V1/guest-carts/CART_ID/estimate-shipping-methods' \
-H 'Content-Type: application/json' \
--data '{"address":{"country_id":"US","region_id":12,"postcode":"9410"}}'

后端不要让输入问题变成500

邮编格式不符合业务规则时应返回可理解的LocalizedException或空的可用运费列表，不能让未捕获的TypeError一路冒到Web API。尤其注意第三方地址标准化服务返回null、数组缺键和地区ID不存在。

try {
    $normalized = $this->normalizer->normalize($address);
} catch (\Throwable $e) {
    $this->logger->warning("Postcode normalize failed", ["exception" => $e]);
    throw new \Magento\Framework\Exception\LocalizedException(
        __("Please check the postcode and try again.")
    );
}

日志里不要记录完整住址和客户信息。保留国家、错误类型、请求追踪ID通常已经够定位。

前端Mixin必须在成功和失败时都结束Loading

return originalAction(messageContainer).always(function () {
    fullScreenLoader.stopLoader();
});

具体Action可能返回jQuery Deferred或原生Promise，不能照抄 always。先确认原函数返回类型；如果是Promise，用 finally。如果Mixin覆盖了原fail处理，还要把messageContainer传回去，否则用户只看到转圈，没有错误提示。

排查Carrier和地址规则

  • 在后台确认国家、地区与邮编是否属于Carrier允许范围
  • 关闭最近新增的shipping carrier逐个测试，找出抛异常的collectRates实现
  • 检查collectRates返回false与返回空Result的语义是否符合当前版本
  • 为外部Carrier API设置连接超时、读取超时和降级策略
  • 确认同一地址在游客和登录客户下都能完成估价

验证修复

准备一个合法邮编、一个格式错误邮编、一个Carrier不服务的邮编。合法地址应显示运费；格式错误应立即展示可读提示；不可服务地址应显示无可用方式而不是永久Loading。然后查看控制台不应有未处理Promise rejection，PHP日志里也不应出现同一异常循环刷屏。

先找出失败请求，再修错误边界。结账页“转圈”只是症状，真正的问题通常已经清楚地写在REST响应和exception.log里。