自己做网站的成本夫妻之间的直播
开始前奏：
嘻嘻😄
通常一个完整的系统，需要安全性的保证。如登录校验，登录成功后，才可以访问服务资源。在服务端渲染项目中，我们通常使用 session来进行登录校验。在前后端分离的场景中，很多时候会采用 token（凭证）的方案来进行登录校验
1. 为什么要进行登录校验？
如果不进行登录校验的话，用户登录的账户只是用户的一个虚拟身份，用于记录信息。而无法判断用户的登录态，万一有人非法获取用户登录信息，那么他可以在另一台主机以该身份访问网站，对真正的用户产生不良影响。如果我们记住用户的登录态，或者保持一段时间内用户的登录，这就很好了。但是服务器无法掌握用户是否时刻在访问网站（不是监控）。由于 HTTP协议的限制，服务器和浏览器端实际是在交换信息，如果想要时刻掌握用户的登录状态，那就需要保持永久的连接，相当于每刻都在登录，这是不可能的。
虽然我们使用一些方式可以保持一段时间的登录态，当超过这个时间用户就需要重新登录，以刷新凭证。这样做算是目前最好的方式了，依据这段时间的登录态，可以防止用户重复登录，当用户超过登录态时间还在登录使用网站，那么也可以刷新登录态时间
2.JWT+token认证原理
用户发起登录请求后，服务器进行验证。如果验证失败，则提示重新登录；如果验证成功，则结合用户信息并通过 JWT生成 token，并将 token 封装到响应体中，返回给前端；然后前端需要保存这个 token。每次发送其他请求时，将 token放到请求头中，服务器获取请求头中的 token，解析 token，验证是否正确，如果正确则允许访问资源，否则返回错误信息给前端。
3.JWT 生成 token 配合拦截器
- 创建登录接口，并生成token
- 通过拦截器统一拦截请求校验token
当前端请求我们的其他接口的时候，我们需要验证 token是否正确且不超时；如果满足我们就让其他接口进行处理，如果不满足则让用户重新登录。但是为什么要使用拦截器统一拦截请求进行处理呢？因为如果我们在每一个接口方法中，都去验证token，这是非常无聊的。而拦截器会拦截请求，也就是在请求之前进行一些处理，用来做 token 校验最为合适。
4.为什么不使用 session 而大费周章的使用 jwt+token 的方案呢？
在现实中，一个庞大的应用，往往不是一个服务器。当与用户访问服务器时，虽然会生成 sesion_id ，当用户再次访问服务器时，可以通过 sesion_id 进行校验，但是如果用户访问其他服务器时，没有这个 sesion_id就访问不了服务器资源。为此我们可以通过 session复制 session粘连 session共享 来解决这个问题，但是这些操作，通常会造成性能消耗。
而 jwt+token 的方式，这种方式 token 保存在浏览器端，服务器只需要校验 token 是否正确即可。多台服务器的话，只需要有一套 token 的校验机制即可。
并且在移动端 Session 验证登录的方式是往往失效的，而 jwt+token 的解决方案也适用于移动端。