捡漏模式分策略执行，以及监控模式

[IMLR]

很多人反应捡漏模式运行几个小时后被封号，应该是存在针对账号查询频率风控，所以能不能把捡漏的策略修改一下？

Delivery：运力优先模式，也就是现在的normal模式，用于运力紧缺的地区，封号风险较高，有货且有运力直接疯狂下单，每次都带登录查询，目测不可连续运行超过两个小时以上（暂时）

Goods ：货品优先模式，用于运力基本充足，但随机上货的地区。提前读取购物车后不带登录查询货品库存状态，封号风险较低，有货且有运力单线程下单，只有下单时才带登录，避免封号

讨论：
1.这个模式应该要设置最低下单金额？
2.这个模式要不要通知“有货但是金额不足没进行下单动作”？
因为可能最低金额设置太高错过多次可下单机会，但通知有可能反复提醒
3.是否要在下单前不带登录从首页预读取当前站点是否运力已满，以防止默认有运力导致反复带登录尝试下单？

另：是否开发纯监控模式？
Notification：单纯监控当前有货商品，因为可能不知道当前站点可能会上什么东西，自己加购物车里的东西一直没货，或者上了同类新商品不知道，没有加购物车

这个我之前写过监控，基本上就是每次读取所有可买商品，和上一次的比较，有新商品则通知。可用于纯手动捡漏
已知坑：
1.有的商品可能反复上架，会重复通知，要有黑名单模式
2.有的商品可能上架了，但由于搜索缓存，搜索结果还是无货，但加购物车有货，可以购买
3.如果看到监控再打开APP找到商品加购物车下单，可能等到结算已经无货了，也可能只能拿来做通知

另外此功能可能对叮咚服务器造成较大压力

最后就是高峰（早6点8点半）使用的
Speed：速抢模式

[Runc2333]

@IMLR 有没有可能搞中心化实现，单设备监控所有站点

[IMLR]

如果监控所有站点对叮咚服务器压力可能变小，但如果能公开访问的话，该模式就失去了手动捡漏的功能了，只能作为参考上架历史信息。因为同地区的人应该很快会关注到这个页面。另外单站点同时推送通知可能不好实现

[xpring]

下午测试了几个小时不带特征的运力监测，cookie、token、header全部去掉，只用https://maicai.api.ddxq.mobi/homeApi/newDetails?api_version=9.50.1&app_client_id=1&app_type=&buildVersion=1229&channel=App%20Store&city_number=0101&countryCode=CN&device_id=&device_model=iPhone9%2C1&device_name=iPhone%207&device_token=%3D%3D&idfa=&ip=&languageCode=zh&latitude=&localeIdentifier=zh_CN&longitude=&os_version=14.6&pageId=homePage&seqid=&sign=&station_id=5500fe01916edfe0738b4e43&time=也可以检测运力。
那么先不登录测运力，有运力立马登录下单，这样捡漏应该不会被风控。

[IMLR]

@Runc2333 似乎不从首页也能读运力哦

[Runc2333]

@IMLR 这个就是首页api

[IMLR]

@IMLR 这个就是首页api
打扰了

[iiwen]

不登录查运力两周前成功过（有可能带了uid什么参数，具体忘了），现在不清楚，我去测试一下