Miles Cheng

> 一通瞎几把乱改后，然后居然可以用了。 改动的地方能给点提示吗？

> 我也不知能用多久，基本改掉涉及如下： > > 1. pay_type > 2. ddmc-app-client-id > 3. ddmc-api-version > 4. app_client_id > 5. ddmc-sdkversion > 6. ddmc-build-version > > 删掉了 > > * device_token 前两个看起来是关键参数，client-id应该不是2吧？

> 完蛋 dingdong 会不会根据订单金额找到我啊，求求各位大佬把引用我的图片删掉吧。pray 引用已更新 (应该不至于找你) 请问你下单后能支付吗？

> > 引用已更新 (应该不至于找你) 请问你下单后能支付吗？ > > 已经送到了 eyes 厉害，坐等分享config 有个疑问，我看你提交过程出现了很多次拥挤的情况，请求响应是405 or 200吗？

兄弟，打码打全啊 另外，你账号可能风控了，你切换到APP上确认一下

> > 小程序更新到2.85.2了,现在完全是抓不到接口了！！ > > 找了下还是有的，换个接口就可以了 已经提pr了 #199 多了一个sdkversion，对吧？

> 失败的，作者逻辑对的 确实会有一些请求会失败，但前面数据一直并行更新，难道不会导致最后提交的数据错误吗？ 比如addNewOrder时，cartMap和checkOrderMap对应不上

> 我用这个已经抢不到，那确定前一步成功之后，再进行下一步不是更合理？否则连购物车都没确定，不停的刷新预约时间也没啥意义 刷新前面的资源是为了更新购物车商品和预约时间，但目前的程序可能会导致下单时数据不一致。 比如下单成功后提示的订单金额和实际付款金额不一致 (当然数值不一致也有可能是DD后台自动扣减导致的)

> 我是因为抢不到了才想这个问题，现在程序是所有步骤一下子全部一起做的 如果不考虑购物车商品更新问题 (特别是购物车新上架商品)，完全可以到时间并发执行addNewOrder这一步，其他部分的数据完全可以在开放前获取到

我今天下的单无法支付，提示下单人数过多