今天完成的事情：（一定要写非常细致的内容，比如说学会了盒子模型，了解了Margin） 

1.早上到下午解决问题，就是UserService一直失败，然后还没问到解决办法，明天问问。

服务器部署结束以后就是测试接口了。

2.然后首先就是微信接口的授权，这个由于当时code由前端发送，所以一直不知道详细过程，全程由后端处理了这个东西后进行了本地测试。

今晚和一前端大佬请教了好久才知道大概详情：

就是正常的菜单-----》回调域名后接的信息是一个前端的页面，比如home，在这里前端进行对code的获取---------》接着发送一个微信授权请求到后端，后接着code的参数--------》后端正常验证一系列接口，用户状态，获取微信接口的情况，最后返回json参数的页面----------》前端根据收到的“code”“message”以及userId等跳到以及背景页面或者显示信息。

比如下图，我的用户我执行了冻结操作后去登录：

就有这个信息，然后点不了。

那属于后端的思路：

就是授权url会跳到回调域名，我们在回调域名后接授权请求---------》这样点击进入后直接带着code进行处理，最后给前端返回信息。

最后这个缺点得到了验证：就是说，回调域名的请求方式是get,所以用户可以看到你的code（这个可能不是很重要，毕竟不是太重要的信息），但是你返回信息时，由于请求是由微信接口直接发过来的，前端没有这个请求，他不知道怎么处理这个返回信息（可能也是可以解决的，现在就是相比来说的缺点）。

然后，其实关于微信调用接口还是主要由前端来做，所以这个才会感觉总有问题，我们只是处理数据就行了。

3.签到接口

获取签到信息一切正常

然后签到时，由于以前都是在白天签到，所以没有出现问题，今天在凌晨签到，然后我的账号报错，别的用户都ok,然后找到不同的地方就是昨天签过到的今天凌晨签到都会显示已签到的信息。

最后打印方法参数，发现零点时间凌晨获取尽然是前一天的，所以获取签到信息会从24-25号凌晨。那么超过24小时的问题就出在这个获取0点时间的地方。

然后拉出测试，一个一个输出看时间处理，最后发现由于我们：

通过int类型处以一天的毫秒数来获取整点天数，最后由于东八区的区时，再减去这个区时就得到零点的看似合理的计算方式其实是在凌晨是有BUG的。

那么由于北京时间早上8点是时间戳的当天0点，所以在0点----8点这个时间的，时间戳是属于前一天的，所以当除以1天以后获得的整天数其实相当于少了一天，（时区问题），但是也不可以直接加一天来解决，因为8点以后就很正常了。

所以我们是把这个时区点给时间戳加上以后再获取正确天数，比如北京时间凌晨3点，加了以后就是北京时间111点，但是时间戳是3点的时间戳，不会去前一天的。当然最后还是要剪掉时区的偏差时间戳，毕竟最后数据是按时间戳来计算的。

所以这里强调不要用时区的方式解决签到问题，很容易出现这样的错误，我们推荐用日历的方式去处理连续签到等问题比较准确。

以下就是签到成功后的页面，总的来说，前端页面还是很OK的。

明天计划的事情：（一定要写非常细致的内容） 

学生部弄好了的话就调试换头像的接口。

遇到的问题：（遇到什么困难，怎么解决的） 

就签到问题。

收获：（通过今天的学习，学到了什么知识）

上面说完了，思路算是由理了一遍。

有点被公共接口毒害了，以及感觉自己设计的方案的处理方式的优点了。看来还是应该多思考思考问题。

另外，前端的页面确实有些出乎意料，以前考虑到可能会有很多问题后端没有考虑到，但碍于公共接口也没办法，然后今天才发现其实是有前端解决了。

比如微信授权成功后，除正常信息以外，还有个userId,这个本来由后端保存后进行执行该用户的一些被授予的功能，但是今天探讨中才发现，前端也可以通过session的方式保存该参数，然后后面涉及到用户的接口，每次都做为参数和请求一起发送到后端进行处理。

看来学习学习前端还是很有必要的。