用户登录态登录态 Http 请求时，服务端无法知道哪个用户请求的，所以会说 Http 是无状态的。但是在一些交互式的系统

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第13天，点击查看活动详情。

登录态

Http 请求时，服务端无法知道哪个用户请求的，所以会说 Http 是无状态的。但是在一些交互式的系统里，需要知道每次请求都是哪个用户操作的，比如购物网站，需要知道谁下单，谁付款。所以登录态就是用来区分用户，让服务器知道是由谁发起请求，谁操作的。

所以登录态，也是一种用户身份的标识。

一个请求过来，若没有找到其身份标识，说明未登录，则需要重新登录，若存在一致的身份标识则可以继续操作

服务器常用的解决请求时身份标识方式：

用户登录时，服务器校验成功后，服务器生成一个 sessionId 返回给客户端，同时服务器也会保存该 sessionId。而客户端得到 sessionId 将其记录到 cookie中。

接下来，每次请求都带着 cookie，其中含有 sessionId，发送给服务器，服务器就可以通过 sessionId 区分出用户

用户登录时，服务器校验成功后，服务器将用户信息封装，加一层密钥生成 token 返回给客户端，服务器不需要保存 token 。客户端也是将 token 存储在 cookie 内。

这样后客户端每次请求时，都携带 token 请求。服务器拿到 token 只需要验签名解析出信息就可区分用户

服务器也需要保存 sessionid，如果用户量特别大，那就需要很大空间或者内存去做存储，但对于 token 来说，无需保存 token。

服务器生成的 sessionId 或 token 都会存储在客户端的 cookie 中。这样就容易发生泄露。

当过期，修改密码，则需要失效其登录态。

session 方式：将 sessionId 存储在 redis 内并同时给一个过期时间，到点就删除该 sessionId 。像其他场景的情况，比如修改密码后，触发删除 sessionId
token 方式：过期时间都包含在 token 里面，过期后 token自动不能使用。其他场景对于过期的控制可能没那么灵活了

允许多端同时登录或者只允许一个端活跃。

若允许同时登录，仅需要登录的时候都返回客户端相同的 sessionId 或者 token。若只允许一个端登录，则仅需只有一个 sessionId 或 token。