Generally there is no need to cache. The advantage is that you don’t need to flash the authorization page every time you open it. If you cache it, you can write it into the session. When you come in, you can check whether there is an access_token and whether it has expired. If it has expired, you can use refresh_token to refresh it (but I They are all used to jumping directly to the authorization page to authorize again, or they have to judge whether the refresh_token has expired, which is too troublesome logically).
No caching required. There is no limit on the number of times an access_token can be called, only the number of times you can apply for an access_token in a day. . In addition, I remember that once the access_token is used once, and then the access_token is not used again for a certain period of time, the access_token will become invalid soon. But it’s not stated in the document
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Generally there is no need to cache. The advantage is that you don’t need to flash the authorization page every time you open it. If you cache it, you can write it into the session. When you come in, you can check whether there is an access_token and whether it has expired. If it has expired, you can use refresh_token to refresh it (but I They are all used to jumping directly to the authorization page to authorize again, or they have to judge whether the refresh_token has expired, which is too troublesome logically).
Unify the statement above and use re-authorization to solve this problem.
No caching required. There is no limit on the number of times an access_token can be called, only the number of times you can apply for an access_token in a day. .
In addition, I remember that once the access_token is used once, and then the access_token is not used again for a certain period of time, the access_token will become invalid soon. But it’s not stated in the document