为什么 那几个操作是并行做
Opened this issue · 12 comments
难道不应该是先勾选购物车，确定成功，然后选时间，一步步来的么？
难道不应该是先勾选购物车，确定成功，然后选时间，一步步来的么？
你自己抢一下就知道了，有些流程会失败的，作者逻辑对的，无需怀疑。今天两次都抢到了
失败的，作者逻辑对的
确实会有一些请求会失败，但前面数据一直并行更新，难道不会导致最后提交的数据错误吗？
比如addNewOrder时，cartMap和checkOrderMap对应不上
我用这个已经抢不到，那确定前一步成功之后，再进行下一步不是更合理？否则连购物车都没确定，不停的刷新预约时间也没啥意义
我用这个已经抢不到，那确定前一步成功之后，再进行下一步不是更合理？否则连购物车都没确定，不停的刷新预约时间也没啥意义
刷新前面的资源是为了更新购物车商品和预约时间，但目前的程序可能会导致下单时数据不一致。
比如下单成功后提示的订单金额和实际付款金额不一致 (当然数值不一致也有可能是DD后台自动扣减导致的)
我是因为抢不到了才想这个问题，现在程序是所有步骤一下子全部一起做的
我是因为抢不到了才想这个问题，现在程序是所有步骤一下子全部一起做的
如果不考虑购物车商品更新问题 (特别是购物车新上架商品)，完全可以到时间并发执行addNewOrder这一步，其他部分的数据完全可以在开放前获取到
你们抢到了能调出来支付页面吗？我一直无法调出来支付，虽然能下单但是无法支付
我今天下的单无法支付，提示下单人数过多
我今天下的单无法支付，提示下单人数过多
我也是一样的提示，不知道是风控了账号还是说需要再改参数
我是因为抢不到了才想这个问题，现在程序是所有步骤一下子全部一起做的
如果不考虑购物车商品更新问题 (特别是购物车新上架商品)，完全可以到时间并发执行addNewOrder这一步，其他部分的数据完全可以在开放前获取到
运力是6点才释放的
我是因为抢不到了才想这个问题，现在程序是所有步骤一下子全部一起做的
如果不考虑购物车商品更新问题 (特别是购物车新上架商品)，完全可以到时间并发执行addNewOrder这一步，其他部分的数据完全可以在开放前获取到
运力是6点才释放的
运力参数可以在6点前获得