Miles Cheng

> > > 我怎么就没设置地址啊，地址填抓包的字符吧？但是我抓包之后，就没有addressid这个选项，有了之后后面的也是空的。 > > > > > > 在叮咚APP或者小程序里把实际收货地址设置成默认值 > > 默认值是把地址删掉再重新抓包？你们说的什么行业属于啊 不需要重新抓包，也和程序没关系 登录你的叮咚客户端，找到你实际的收货地址 (对应设置的叮咚station ID)，把它编辑成默认收货地址

> > > > > 我怎么就没设置地址啊，地址填抓包的字符吧？但是我抓包之后，就没有addressid这个选项，有了之后后面的也是空的。 > > > > > > > > > > > > 在叮咚APP或者小程序里把实际收货地址设置成默认值 > > > > > > > > > 默认值是把地址删掉再重新抓包？你们说的什么行业属于啊 >...

> > > 明天早上如果测试成功的话，分享一波我改的 有没有大佬解决一下支付不进去的问题，跪求，解决了一定第一时间发您我改的，可以买菜助手app等思路，反正只要能付进去就好了 > > > > > > 你要是用银行app的clientId，需要修改addNewOrder的pay_type > > > > 大佬这图哪里来的，太牛了 这个是抓包出来的，checkOrder的响应文件

> log/bundle这个到底是什么用啊，我看送达时间好像调用这个啊@[Meteor0928](https://github.com/Meteor0928) 叮咚升级版本后，页面的点击操作通过log日志上传到叮咚服务器

我看其他项目里有人说，DD可能启用了签名验证

> > 我看其他项目里有人说，DD可能启用了签名验证 > > 有提到怎么解决吗 目前还没有提供解决方案

> > 我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的 > > 我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。 根据最近的情况来看，瓶颈确实不在配送这块，主要是库存不足

> > > > 我理解的是，高峰期下单过程中"购物车"+"派送时间"这两个请求应该要一直刷新，这样才能保证最后Check & Submit订单的数据是准确的 > > > > > > > > > 我也知道这一点，但实践问题是，这二个在高峰时就会不断产生，前向拥堵,然后不停的刷新，封账号也会因为这个产生。派送时间这个绝对可以延长，目前DD，把派送时间加的很大，所以几秒内是不会有问题的。 > > > > 根据最近的情况来看，瓶颈确实不在配送这块，主要是库存不足 > > 每个地方不一样，运力基本能坚持5分钟以上，但库存涉及到单 个商品，变数多，所以运立的检查不用怎么平凡去刷。 程序运行确实存在逻辑问题。由于一直while刷新，前面获得的数据到后面可能都改变了(比如购物车商品变化)，导致最终check以及submit的数据是错误的

> > 想问一下你的deviceid和deviece-token是都没有填吗？我没有抓到这两个参数 > > 请求头的deviceId为空 device_token有的 是在请求的参数里面 不是请求头里面 能发个完整版的抓包信息吗？删去你个人信息的那种

> > > 刚下了一单，完全正常。秒抢 > > > > 你改了什么？我这边一直拥挤。 > > 加了headers.put("ddmc-sdkversion", "2.23.4"); > 别的参数更新成最新抓到的数据，别的都没动 sdk这个值我用的昨天的，下单没问题，就是下单时间长了些 请问你有更新代码其他部分吗？比如sleep time