玩家由于网络波动造成短线重连，需要知道的是，网络问题，我们能做的只是兼容处理，不能完美解决。网络问题分两种情况：
一、客户端向服务器发协议之前就断网了；
二、客户端向服务器发完协议之后断网了；
断网能引发一系列问题，查代码，逻辑又是没问题的，下面以刮刮卡为例说明断网造成的影响，以及相应的解决方案
逻辑是，刮卡之后，客户端进行记录，记录后，该道具再次请求刮开时会被拦截，这么处理是为了避免客户端在收到服务器返回协议之前，客户端又请求了刮开，导致提示道具不存在。如果刮到道具，服务器通过协议清除掉背包中那个道具；如果刮到现金，服务器不清楚背包道具，但是没有刷新背包单个道具数据的协议，所以改成客户端给单个道具进行现金金额赋值
一、客户端向服务器发协议之前就断网了
造成的问题就是，客户端这时候无法知道用户是否断网，按照有网的逻辑进行了一些处理，而实际上用户这时候断网了，那些就不应该做这些处理，这些处理造成的结果都是有问题的。博主这个需求是只要走到了客户端发协议这里，就从list列表删除指定刮刮卡。出现这种断网情况后，造成的后果就是，这张卡实际没有被挂掉，但是被客户端从列表清除掉了。不过，只是从列表清除，背包中还是存在这张刮刮卡的。所以影响并不大，而是用户可以刷新重新登录，这样又能重置这个列表了。
二、客户端向服务器发完协议之后断网了
造成的问题就是，无法收到服务器返回的协议，没有做成功刮开之后的客户端处理。博主这个需求，刮开之后要播特效，如果是现金红包，还要给道具进行现金赋值。结果就是，这张卡明明已经刮开了，但是由于没有收到服务器返回协议，导致客户端仍然认为这张刮刮卡没有刮开过。自然也不会播放特效了。
----------
针对以上两个问题，并没有完美的解决方案。客户端需要在道具被用掉之后做相应处理，那么什么时候判断道具被用掉了呢？要么是客户端代码走到了这一步就认为道具已经被用掉了，要么是收到服务器返回协议之后才认为道具被用掉了。两种方案，相对而言，服务器数据更可靠，所以最终采取的方案是收到服务器返回协议之后才视为道具被用带了。而博主的这个需求，要做的只是从列表清除，并没有从背包清除。
分析一下获得道具奖励的情况，1、如果在客户端代码执行到请求协议那一步，就从列表清除，后果是道具实际没用掉，但是已经清掉，想再次使用，则必须打开背包使用。对于服务器返回协议之后的处理，只有特效，想想其实这样处理没多大影响；2、如果在收到服务器返回协议之后，再从列表清掉，后果是道具其实已经用掉了，但是客户端没有从 list列表清掉，仍然能从list列表使用该道具，再次请求使用会提示道具不存在。博主最终采取了方法1。
再分析一下货的现金大奖的情况，现金大奖不会清除道具，所以不存在道具不存在这种问题。对于服务器返回协议之后的处理，只有特效和金额赋值，特效其实影响不大，那么还剩金额问题，金额是服务器抽的，所以必须要在收到服务器协议之后才赋值。这张开明明已经中奖了，但是没收到数据，所以客户端允许再次请求刮将，而服务器那边对于已经中了现金大奖的刮刮卡，不会返回协议，最后会导致这张卡无法刮开，除非玩家刷新重登，这样背包会更新到服务器记录到的数据。这个影响就比较大了，玩家是不知道要刷新重登的，最后会向客户反馈这张卡无法刮开，客服登号发现这张卡已经刮开，如果离活动结束时间比较近，会导致玩家错误最后兑奖时间；解决方法有两个：1、断线重连后，服务器推送背包数据和列表数据以及其它一堆不知名的协议，这样做很可能会少发某些协议；2、对于已经中了奖的刮刮卡，再次请求刮卡时，返回服务器记录的数据，如果需要发奖，则不发奖只发数据。最后采取了方法2.
----------
之前做需求从没考虑过断线重连问题，很多不知原因，无法重现的BUG很有可能都是短线重连造成的
