基于分布式系统、同公司内、同一个 redis 作为存储，这个是目前主要的用法，去找开源框架都是这个逻辑；对外开放等使用参考 OAuth 2.0

能够标识出用户是谁，安全性相对高一些，就是好的方案。

Cookie

Set 和 Get：

• 服务端控制 Set： 服务器可以通过 HTTP 响应头中的 Set-Cookie 字段来设置 Cookie。如果浏览器没有找到相应的 Cookie，服务器通常会设置一个默认的 Cookie。——通过服务端渲染，返回给前端的代码也可以拼接上前端主动setCookie也行
• 浏览器处理： 浏览器接收到 Set-Cookie 后会自动存储和管理这些 Cookie。当浏览器再次向同一服务器发送请求时，它会自动将所有相关 Cookie 附加到请求头中。

Session

会话 ID：

• 服务器为每个用户创建一个唯一的会话 ID，并将其存储在服务器端（如redis、Db等）。
• 会话 ID 通常会被包装在一个名为 sessionid 的 Cookie 中，这样浏览器在每次请求时都会自动携带这个 ID。
• 服务器通过会话 ID 来识别用户，并获取与该用户相关的会话数据。

JWT（JSON Web Token）

用户信息加密字符串：

• JWT 是一种用于在网络应用间传递声明的开放标准（RFC 7519）。它由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。
• JWT 的载荷部分可以包含用户的身份信息和其他相关数据。这些数据在服务器端进行加密处理后生成 JWT 字符串。
• 由于 JWT 是自包含的，因此可以减少对数据库的查询。但是，JWT 不易于实现下线处理，因为一旦签发，它将在其过期时间之前一直有效。为了解决这个问题，通常会在服务器端（如 Redis）存储一份 JWT 的副本，并设置相应的过期时间。当需要强制用户下线时，只需删除 Redis 中的对应记录即可。

Token（跟 SessionId 差不多）

服务端生成和 Redis 存储：

• Token 是一种用于身份验证的字符串，通常由服务器生成并返回给客户端。
• 与 JWT 不同，Token 可以是任何格式和长度的字符串，只要它能够唯一标识用户即可。