微信开发中遇到的access_token坑 ,access_token失效和刷新

这真是一个巨大的坑，为了避免以后踩到同样的坑和帮助刚接触这块的同学快速脱坑，我花了些时间研究问题的来龙去脉，提供了一个不太完美的解决方案，以及未来规划的完美解决方案。

问题现象

在开发微信jssdk的图像接口功能时，测试环境和回归环境都ok。但是更新到预发布环境后，功能就异常了，一直报图片下载失败。最后快到发布时间时，功能又恢复正常了。于是按照常规流程进行了发布。过了两天，收到线上反馈的问题：用户刚开始还能正常传图，用着用着就突然报错说传图失败，然后就一直不能用了。我们在测试环境模拟测试，功能又是正常的:(

查找原因

这种偶现的问题一般都很难迅速定位到具体原因，而且本地和测试环境正常，预发布环境和线上异常，但是又不能进行调试。于是只能根据代码逻辑进行猜测性判断和尝试修复，中间走了大量的弯路，最后发现，删除存储access_token的redis值，再使用时功能正常。

技术分析

问题暂时解决了，但这不是长久之计。于是我花了点时间阅读官方文档，发现这果真是个大坑啊！官方文档原文如下：

第一个红色框里的内容，我测试了三次，第一次连续请求13遍，access_token发生了变化；第二次连续请求12遍，access_token发生了变化；第三次连续请求19遍，access_token发生了变化。（坑一）

第二个红色框里的内容，我们有开发环境，测试环境，回归环境，预发布环境，正式环境，都是同一套代码，同一个微信号，相当于每个环境都是单独的中控服务器。（坑二）

现场还原

搞清楚问题后，我们通过一些手段尝试性的触发问题现象：

1、测试环境下，清空access_token的redis数据。

2、正常测试，功能ok，查看access_token的redis内容，这里假设值为A。

3、手动调用接口刷新access_token，大概十几次后，值变化为B。

4、再次正常测试，发现功能异常（因为此时存储在redis的access_token已经过期）。

5、清空access_token的redis数据，再次测试，功能又恢复正常。

现在问题终于变成必现的了:)

解决方案

现在我们搞清楚问题的原因是存储在redis的access_token可能在很短的时间内过期（因为有太多中控服务器啦），但是我们一般设置的有效期都接近或等于7200s，这就导致一旦出现问题的话，如果不清理redis，问题就会持续2小时左右，这简直就是灾难！

目前想到的比较理想的解决方案就是：服务器发现功能异常时，刷新access_token并更新redis，然后再次调用接口。这种容错机制本来是微信的事-_-！

未来规划

正如开头所说，这的确是个巨坑，未来只能期望微信获取access_token的接口能够完善：

1、说好的2小时过期时间，就得保证2小时内不过期

2、返回的过期时间字段为还剩多少秒过期，而不是每次都返回7200s

然而微信并没有