背景

前台的变更：

app3.0版本将原先在app上的签到入口转了h5页面中。

后台的变更：

签到不再调用原先app-api模块的接口，而是调用creditmall-api的接口，也就是说将签到从那边转了过来。

数据库：

签到表从dbapp转移到了dbcreditmall

产生的问题：

android，ios的3.0上线时间是不一样的，积分商城签到的上线时间与以上2个也是不一样的。如果积分商城先上，那么会出现2个签到，app＋积分商城h5。如果android/ios先上，那么会出现没有签到入口。签到得积分的规则是每天：5.10.15.20.20.20...因为签到表的不同，新的表是空的，所以头3天不管用户累计签到了多少天，都只能从5分开始累计。而且如果以后需要统计签到总的记录时，会比较麻烦。

解决的思路

多签到问题：

因为2个版本的客户端，以及积分商城的h5上线时间都是不一样的，所以出现2个签到的入口时不可避免的。现在要避免的是：用户一天签到2次，其实就是往2个数据库的2张表里插了2条数据，又分别给用户加了积分。而我这恰好又有积分记录明细表，可以通过这个表来判断用户是否签到过了，然后h5中再决定是否让这个按钮失效，这样是比较友好的。这样做我这边是没有问题了，他那边签到完了再来我这页面，我能够知道他已经签到过了，能假装是同一个入口。但是如果用户是先进的h5（我这）签到，再去app上签到，这就没有办法了，这再去修改原先签到的判断接口。所以第一种解决方案就是：修改签到状态判断的接口。新旧2个模块同时修改。不管新的旧的，签到的时候都得调用积分商城service的加积分服务。如果我把上面的判断加到了这个地方（虽然听上去有些不合理），那么只需要修改这一个地方就行了。但是与上面不同的是：上面做的能够使得签到按钮变成已签到状态，做到以假乱真；而这里只能做到点了签到后不给你加分，或者是再告诉你你之前签到过了。第一种方法比较合理，但是麻烦；第二种方法稍微简单了一点，但是感觉不怎么合理。所以我们采用了第三种方法：不管了，，，让他多签到一次又何妨！！

累计签到断点问题

要解决这个，相比上面的问题，是要简单的多。虽然没有签到记录表可以差，但是又积分记录明细表可以查。选择指定用户id，积分类型为签到，然后再来个日期范围，直接就查到数据，知道现在应该是第几次签到了。所以最终的解决方案就是：前后差不了几分，不管他了。。。。

总结

应对多签到问题：

新旧入口都加判断

应对签到断点问题：

没签到表查的时候去查积分明细表再加以分析

最终的解决方案：

不管他