author2.0内存可以存储多少条token

Author20的内存大小是取决于服务器的配置和存储设备的大小的，不同的服务器和存储设备会有不同的限制。在理论上，如果内存足够大并且存储设备足够强大，Author20可以存储无限制数量的token。然而，在实际应用中，受到硬件和软件的限制，通常的内存大小可以存储几十亿个token。因此，对于一般的使用场景，作者可以根据需要选择适当的硬件来满足内存大小的需求。

四种方式

Cookie 出现的原因： >

上一篇文章我们了解了一下 cookie 与 session 的产生、作用与原理。尽管二者在历史中已经服役过很长一段时间，但不论什么技术，都会有后来的优秀者取而代之。

前面说到，cookie 因为是保存在客户端，所以有安全隐患，因而诞生了 session，session 保存在服务器端，相对安全很多。但 session 每次都要为用户开辟一个空间用于其身份校验，且每次浏览器的请求过来服务器都要进行校验请求，十分耗费服务器的空间与性能。

于是，另一种身份校验工具诞生了，这就是 token。

本质上还是用户身份验证的工具。但与 cookie、session 明文似的形式不同，token 是经过一系列加密手段加密过的，最后表现为一串“无意义”的字符串。但里面包含了许多信息，可能包括用户登录的终端的地址、用户身份 ID、时间戳以及一个签名。所谓签名就是信息发送者给这段信息进行签名，让信息接收方知道请求 token 是属于谁。可以理解为在你的身份z上签名字，证件加笔迹双重认证。

为了避免上述 CSRF 攻击，浏览器对网页资源的访问提出了限制，URL 请求必须是与页面一样来自同一 协议 、 域名 、 端口 才给予访问权限。这样三者相同的站点被认为是有相同的“源”，是一个独立的“域”。即使 “localhost” 与 “ip” 都指向了本机，但也会被认为是非同源。浏览器在某个“域”下不会执行其他“域”的脚本。因而这也产生了前端领域里一个重要的话题：跨域。

session 的产生来自于用户登录后服务器生成的一个 session 对象，保存在服务器端，这个 session 只适用于该“域”。但实际情况是，一个网站的请求大多数情况下都会跨域，每台服务器的端口不同，甚至是域名就不同，每当跨域时就会形成新的会话，生成新的 session，这是非常影响用户体验的，所以也会有许多保存、共享或中央存储 session 的方案。

但上述两种限制在 token 这里就不再是问题。

与 cookie 类似。

首先，用户输入账号密码，发起登录请求，服务器校验账号密码合法性，成功则返回 token 给客户端。

客户端收到响应后拿到 token，将其通过 localStorage 等本地存储方式进行保存。

当浏览器再次请求时，需要在请求头中添加 token，这样服务器在接收到请求后便可以识别该请求的身份是否合法，合法则返回响应数据。

在实际应用中，配合 axios 的请求拦截器使用起来会很方便：

这样，就不用每次请求都手动添加 token，axios 会自动帮助我们完成添加，十分方便。

其实前端程序员对 token 的涉及没有多深，只需要在需要授权的请求中携带 token 即可。token 的生成、加密等都是后端去处理。所以，这里也就不在赘述 token 的加密原理，以笔者的能力也很难去讲述清楚。

token 运用也不是上文中描述的那么简单，涉及到一些过期处理、refresh 等 *** 作。这些日后有机会再详谈。

>