当前结账设计当我们通过单选输入切换交付方式时，一旦点击，就会向后端发送三个连续的HTTP请求：当我们点击发货时method，会向后台发送三个串行HTTP请求。从Chrome开发者工具的时序图中可以清楚地看到这个串行请求的行为。Request1:HTTPPUTtosetdeliverymodeurl:https://20.83.184.244:9002/oc...这个HTTPput请求用来修改订单的发货方式。此请求在delivery-mode.component.ts中触发，方法为changeMode。模式修改的触发从服务类的setDeliveryMode开始。该调用将委托给以下服务类：Request2：HTTPgettoload[MultiCart]MultiCartDatahttps://20.83.184.244:9002/oc...,potentialProductPromotions,appliedProductPromotions,potentialOrderPromotions,appliedOrderPromotions,entries(totalPrice(formattedValue),产品(图片(全),库存(全)),basePrice(formattedValue,value),updateable),totalPrice(formattedValue),totalItems,totalPriceWithTax(formattedValue),totalDiscounts(value,formattedValue),subTotal(formattedValue),deliveryItemsQuantity,deliveryCost(formattedValue),totalTax(formattedValue,%20value),pickupItemsQuantity,net,appliedVouchers,productDiscounts(formattedValue),user,saveTime,name,description&lang=en&curr=USD这个HTTPGET请求是在代码中触发的：checkout.effect.ts,之前的HTTPPUT请求成功完成后：当HTTPPUT执行完成后，重新加载Cart：请求3：HTTP获取加载[Checkout]CheckoutDetailshttps://20.83.184.244:9002/oc...(FULL),deliveryMode，支付Info(FULL)&lang=en&curr=USD在checkout-details.service.ts的第59行触发。当第二次HTTP请求完成时，购物车再次稳定，因此触发loadCheckoutDetails方法。购物车成功加载后（稳定），加载结帐详细数据：当前设计的问题让我们看一下checkout-delivery.service.ts。当用户切换交付模式单选输入时，它并不意味着HTTPGET请求将自动发送到后端。下面第244行的语义是：无法触发HTTPPUT请求，除非满足两个先决条件：购物车稳定检查加载完成。通过Actions执行setDeliveryMode的行为是受保护的，只有在Cart稳定且isLoading为false时才执行：happypath:15:42:31355usertogglewithstandarddeliverymode15:42:31360sincecartisstable,checkout加载为假，因此触发HTTPPUT请求15:43:31361HTTPPUT请求被触发在在慢速3G网络上测试会有问题在慢速3G网络下测试，我们现在遇到麻烦了。恢复场景移动到交付模式页面。StandardDelivery无线电输入被选中。单击“PremiumDelivery”。无线电输入已禁用-按预期工作。无线电输入已启用-按预期工作切换回“标准交付”。预期行为：无线电输入再次被禁用。当前行为：无线电输入未禁用。以下是标准交付后的时序再次点击输入（上述测试步骤4）15:45:57用户点击“Standarddelivery”15:45:57isStable为false，因为此时之前选择的premiumDeliverymode的cartloadHTTPGET请求仍然是在途中。15:45:59第二个HTTPGET请求已完成。15:45:59针对先前选择的高级交付模式的第三个HTTPGET请求（加载结帐详细信息）被触发。15:45:59两秒后用户点击“Standarddelivery”，但是HTTPPUT请求仍然无法触发，因为isStable=falseXHRlogCart现在稳定了，isLoading=true，因为第3个HTTPGET请求还在路上。先前选择的高级交付模式的第3个HTTPGET请求已完成。15:46:02购物车稳定，isLoading=false。好的，现在是时候为“标准交付”触发HTTPPUT请求了。不幸的是，用户点击“标准交付”后总共过了5秒。目前，我们通过deliveryModeSetInProcoess$禁用无线电输入。但是，它的值只有在有HTTPPUT请求时才能更改发送到backend.deliveryModeSetInProcoess$的值只有在发送HTTPput操作后才有机会被修改deliveryModeSetInProcess$=this.checkoutDeliveryService.getSetDeliveryModeProcess().pipe(地图（（状态）=>状态。加载））；而HTTPput有两个外部依赖：如上所述，HTTPPUT请求发送有两个外部依赖：购物车稳定结帐加载已完成。这意味着仅使用deliveryModeSetInProcess$来锁定UI是不安全的。下图中红线上方的三个请求代表点击StandardDelivery后的HTTP请求。一般来说，下图中红线上方的1~3个HTTP请求代表StandardDeliveryradioinputclick发送的请求。下图中红线下方的三个请求代表点击StandardDelivery后的HTTP请求。点击PremiumDelivery单选输入红线下方的1~3个HTTP请求。如果用户在时间戳t1之后单击PremimuDelivery无线电输入，即在标准交付的第3个HTTP请求完成后，我们是安全的。如果用户在时间t1戳戳后点击PremiumDelivery，此时是安全的。下面是一个愉快的路径：t2>t1Bad路径：T0：HTTPPUT请求已完成。收音机输入再次启用。如果用户在(t0,t1)之间点击无线电输入，用户可以多次在无线电输入之间切换，但是不会发送HTTPput请求（购物车应该是稳定的，checkoutloading应该是false）基于Jerry的观察：这样的HTTPput请求将自动排队并发送，直到cartStable=true和checkoutloading=false再次。任何用户在t1之后点击将导致并发HTTPPUT请求发送到后端。反之：在t1之前切换input，此时inputradio无法锁定，但是点击不会直接触发HTTPPUT操作，而是加入到队列中。然后当t1到来的时候，这些请求就像失控的页码一样并发的发出去。Jerry测试时序测试准备：选择PremiumDelivery。假设等待20秒，直到所有三个HTTP请求（1PUT和2GET）都完成。测试序列：选择“标准交付”。无线电输入被禁用。按预期工作。等待无线电输入再次启用。按预期工作。选择“高级交付”。由于问题，无线电输入不再被禁用。此时，立即点击“标准投放”。在console.log上解释：Part1:radioinputisdisabled。发送HTTPput请求。第2部分：再次启用无线电输入。第3部分：16:57:02触发“标准模式”的HTTPGET请求。16:57:03用户单击“高级交付”。不会发送HTTPPUT请求。第4部分：16:57:04选择“标准传送”。不发送HTTPput请求。Part5：只有当CartStable为true并且isLoading为false时，才会发送HTTPput请求。并发的HTTPput请求本身并不会出错，但是会导致随后的HTTPGET操作返回错误。并发HTTPPUT会导致后端API执行出错：更多Jerry原创文章在这里：《汪子熙》：
