Greasy Fork is available in English.
淘宝、天猫、聚划算、京东、苏宁、唯品会、华为、耐克、魅族、小米有品、考拉自动抢购工具，支持淘宝、天猫、聚划算、京东、苏宁易购、苏宁香港、唯品会、华为、耐克、魅族、联想、华硕、小米有品、考拉的商品页面抢购、购物车抢购，在非抢购页面支持淘宝、天猫、京东、苏宁易购隐藏优惠券领取及历史价格查看。
< Valutazione su 淘宝、天猫、聚划算、京东、苏宁、唯品会、华为、耐克、魅族、联想、华硕、小米有品、考拉抢购助手v2
您好，尊敬的作者先生
关于提前时间，是不是宜小不宜大？比如自动下单下单频率设为默认的1000ms,采用服务器时间选上后，我和服务器之间的ping值假设为10ms,那如果我设置成提前110ms应该会在抢购开始前100ms下单，这样的话本次下单其实是作废的，实际真正下单是在失败下单的1000ms以后也就是已经开始抢购的900ms才会正式下单，请问是这个情况嘛
您客气了，您的理解大致是正确的。您描述的是代码逻辑，完全正确。
但是放到实际中，并不一定成立。
1.理论上是提前时间越小越好，不考虑其他因素，理论上是0，但事实上并不是
2.提前时间并不一定是ping服务器的时间，下单的整个过程包括了页面跳转时间，提交订单时间，而提交订单时间又大致包含了账号优质判断时间，订单信息返回时间和订单确认时间，这个过程看似很短，但也影响抢购，所以第一点中的提前时间，应该是脚本执行页面到达订单提交页面的时间，而实际下单时间还要加上订单提交时间。
您好，尊敬的作者先生
关于提前时间，是不是宜小不宜大？比如自动下单下单频率设为默认的1000ms,采用服务器时间选上后，我和服务器之间的ping值假设为10ms,那如果我设置成提前110ms应该会在抢购开始前100ms下单，这样的话本次下单其实是作废的，实际真正下单是在失败下单的1000ms以后也就是已经开始抢购的900ms才会正式下单，请问是这个情况嘛您客气了，您的理解大致是正确的。您描述的是代码逻辑，完全正确。
但是放到实际中，并不一定成立。
1.理论上是提前时间越小越好，不考虑其他因素，理论上是0，但事实上并不是
2.提前时间并不一定是ping服务器的时间，下单的整个过程包括了页面跳转时间，提交订单时间，而提交订单时间又大致包含了账号优质判断时间，订单信息返回时间和订单确认时间，这个过程看似很短，但也影响抢购，所以第一点中的提前时间，应该是脚本执行页面到达订单提交页面的时间，而实际下单时间还要加上订单提交时间。
那这样的话，有没有一个比较准确的办法计算出合适的提前抢购时间呢
您好，尊敬的作者先生
关于提前时间，是不是宜小不宜大？比如自动下单下单频率设为默认的1000ms,采用服务器时间选上后，我和服务器之间的ping值假设为10ms,那如果我设置成提前110ms应该会在抢购开始前100ms下单，这样的话本次下单其实是作废的，实际真正下单是在失败下单的1000ms以后也就是已经开始抢购的900ms才会正式下单，请问是这个情况嘛您客气了，您的理解大致是正确的。您描述的是代码逻辑，完全正确。
但是放到实际中，并不一定成立。
1.理论上是提前时间越小越好，不考虑其他因素，理论上是0，但事实上并不是
2.提前时间并不一定是ping服务器的时间，下单的整个过程包括了页面跳转时间，提交订单时间，而提交订单时间又大致包含了账号优质判断时间，订单信息返回时间和订单确认时间，这个过程看似很短，但也影响抢购，所以第一点中的提前时间，应该是脚本执行页面到达订单提交页面的时间，而实际下单时间还要加上订单提交时间。那这样的话，有没有一个比较准确的办法计算出合适的提前抢购时间呢
这个很难精确，只能折中，所以才有参数放出来给大家自己设置，一般建议按默认值。
不同账号优质程度不同服务器返回时间就会不同，不同商品抢购放库存时间也不一定相同，所以很难精确计算，除非您每次盯一个商品，并且抓包分析，但一般的用户是做不到的。
您好，尊敬的作者先生
关于提前时间，是不是宜小不宜大？比如自动下单下单频率设为默认的1000ms,采用服务器时间选上后，我和服务器之间的ping值假设为10ms,那如果我设置成提前110ms应该会在抢购开始前100ms下单，这样的话本次下单其实是作废的，实际真正下单是在失败下单的1000ms以后也就是已经开始抢购的900ms才会正式下单，请问是这个情况嘛