go版本提示access_token_expired
sola97 opened this issue · 7 comments
运行第二天就token过期了
我也遇到这个问题，有解么？
�可以试试云函数版本哈，应该没这个问题
access_token的有效期通过返回的expires_in来传达，正常情况下为7200秒（2小时），有效期内重复获取返回相同结果，过期后获取会返回新的access_token。
企业微信可能会出于运营需要，提前使access_token失效，开发者应实现access_token失效时重新获取的逻辑。
看了一下官方文档，有这么一条，目前token是在redis里缓存7000秒的,所以如果一旦企业微信让token提前失效，会导致这种情况，等后续加一个针对token失效的异常处理吧。
access_token的有效期通过返回的expires_in来传达，正常情况下为7200秒（2小时），有效期内重复获取返回相同结果，过期后获取会返回新的access_token。
企业微信可能会出于运营需要，提前使access_token失效，开发者应实现access_token失效时重新获取的逻辑。看了一下官方文档，有这么一条，目前token是在redis里缓存7000秒的,所以如果一旦企业微信让token提前失效，会导致这种情况，等后续加一个针对token失效的异常处理吧。
针对token失效的异常处理有两个方案:
一: 触发异常后, 重新获取 access_token, 然后 post_response.
二:
在写入 radis 数据库之前, 对 expires_in(凭证的有效时间) 进行判断.
少于7000秒, 就设置缓存过期时间为 expires_in 真实时间的 97%.
或者直接将 radis 数据库缓存过期时间为 expires_in 真实时间的 97%.
�可以试试云函数版本哈，应该没这个问题
企业微信可能会出于运营需要，提前使access_token失效，开发者应实现access_token失效时重新获取的逻辑。
没有在代码中看到有针对token失效的异常处理有, 或者 expires_in 提前判断.
�可以试试云函数版本哈，应该没这个问题
企业微信可能会出于运营需要，提前使access_token失效，开发者应实现access_token失效时重新获取的逻辑。
没有在代码中看到有针对token失效的异常处理有, 或者 expires_in 提前判断.
云函数版本，半小时获取一次
access_token的有效期通过返回的expires_in来传达，正常情况下为7200秒（2小时），有效期内重复获取返回相同结果，过期后获取会返回新的access_token。
企业微信可能会出于运营需要，提前使access_token失效，开发者应实现access_token失效时重新获取的逻辑。看了一下官方文档，有这么一条，目前token是在redis里缓存7000秒的,所以如果一旦企业微信让token提前失效，会导致这种情况，等后续加一个针对token失效的异常处理吧。
针对token失效的异常处理有两个方案:
一: 触发异常后, 重新获取 access_token, 然后 post_response.
二:
在写入 radis 数据库之前, 对 expires_in(凭证的有效时间) 进行判断.
少于7000秒, 就设置缓存过期时间为 expires_in 真实时间的 97%.
或者直接将 radis 数据库缓存过期时间为 expires_in 真实时间的 97%.
企业微信官方就给的7200秒，不管什么时候获取都是这个过期时间 ，目前go版的代码是缓存7000秒，如果按照他的文档说的是没问题的，只是有时候，他不到7200秒自己就会让你token过期，所以目前考虑最快捷的方法就是token过期时候，直接把redis的key删掉，再重新获取就行了