如果access_token误传会导致不可用

[SoberChina]

简要描述

如果遇到token误传 会导致死循环，同时也会导致接口获取access_token 超限。

模块版本情况

• WxJava 模块名: mini-app
• WxJava 版本号:3.6.0

详细描述

在遇到获取access_token 超时，无效，不合法。然后会强制刷新access_token ，当然在获取正常操作下会没有问题。因为access_token 是在config 内存中存储、redis中存储。如果set 值和获取值的对象不一致时，会变成死循环，一直提示access_token无效，严重的话会到值API调用次数上限。
当然有设计重试。为什么不把这一步放到重试中去呢？无效的话不应该一直重试。希望能改进，虽然这是用这个工具的人问题。我相信应该有很多人去重写 service实现 redis实现 等等。因为我重写的时候误写了一个key的问题。导致接口一直无效。
code

[SoberChina]

个人意见，只把access_token强制过期就好了，交给重试去重新获取新的access_token。当然重试是个配置可选项，当然项目中默认是5次，如果强制设置成0 的话 风险就由开发者承担了。

[binarywang]

你为啥要重写 service实现？应该没有太多人会这么做吧。
你如果想使用redis来存储token，有对应的redis config实现，替换下就可以

[SoberChina]

现在基本是都是spring全家桶。RestTemplate 用户可以自定义client ，而且还有比较好用Interceptor 记录输入输出日志。还有应该用redisTemplate的比较多吧。当然直接按照文档上用完全ok ，比如有严格命名规范redis key设计有可能和一些公司不太相符。在扩展redis config的时候 比如key用的不恰当，很容易出问题。相比 jdk8对hashmap 扩容优化一样，众所周知hashmap不能用在多线程下，然而jdk7在多线程上会出现死锁。jdk8为什么会优化一样，代码严谨问题。只是我个人意见，当然我重新service为了使用封装好的resetTemplate，也根据需求把相应的重试修改，重写config为了方便key的命名规范（公司业务上的）。在初期使 只是修改不当的话会有问题。个人意见而已。

[SoberChina]

有重试机制很不错，在access_token 过期的情况下，根据逻辑应该试着去让存key的db过期，交给重试去处理。我的理解重试是在有特殊情况下去处理的，access_token无效当然是其中一种。在默认重试5次的情况下，恰好前四次都需要重试，这时access_token 过期了，按照代码流程，然后再一次开始直到最大重试5次 ，这时重试的次数是4+5=9次 与配置的5次设计不太相符。access_token过期应该也是重试的一种，需要特殊处理也是强制过期redis key 下一次再去换取新的access_token。仅是个人意见。

[SoberChina]

重写service 与config 仅是导致出现这种情况下另一种错误（我的错误），导致获取access_token日获取超上限。重试与access_token 超时，无效，不合法。是否重试应该是主题。

[binarywang]

你有什么好的修改建议，可以直接提交PR

[SoberChina]

那么 这个autoRefreshToken 配置也就没有什么意义了。我的建议是在出现超时，无效，不合法。强制将access token过期掉。pr稍后提交。

[binarywang]

终于看明白你的问题所在了，其实小程序模块有 autoRefreshToken 这个方法就是给你解决这个问题用的，企业微信暂时没有，不过可以加上