高频面试-cookie, token, session
1. cookie:
第一次发送到服务端，服务端返回cookie到客户端，客户端以后每次请求就会带着这个cookie，
使用cookie的缺陷：
使用cookie来保持登录状态是一种常见的会话管理方式，它通过在客户端存储用户信息来实现用户的持续认证。然而，这种方式也存在一定的缺陷和风险，以下是一些主要的缺陷：
-
安全性问题：Cookie中的信息可能会被截获或篡改。如果攻击者能够访问到用户的cookie文件，他们可能会窃取用户的登录凭证，从而冒充合法用户进行操作。此外，如果cookie未设置HttpOnly属性，那么它们可能通过JavaScript被访问，增加了XSS（跨站脚本）攻击的风险。
-
隐私泄露风险：Cookie中的数据可能会被未经授权的第三方获取，尤其是在公共网络环境下，如网吧、图书馆等地方登录时，其他人可能会利用网络监听工具获取cookie中的敏感信息。
-
浏览器兼容性问题：不同的浏览器对cookie的支持可能存在差异，这可能导致某些用户在使用特定浏览器时无法正常使用基于cookie的登录状态保持机制。
-
跨域问题：当应用部署在多个域名下时，cookie的跨域共享可能会受到限制，这需要通过额外的配置来实现跨域cookie的共享，增加了系统的复杂性。
-
存储限制：每个站点最多只能保存20个cookie，且每个cookie的大小不能超过4KB，这限制了可以在cookie中存储的信息量。
-
用户体验问题：用户可能会因为各种原因（如清理浏览器缓存、使用隐私模式等）导致cookie丢失，从而需要重新登录，影响用户体验。
-
法律合规问题：在某些国家和地区，对cookie的使用有严格的法律法规要求，企业需要遵守这些规定，否则可能会面临法律风险。
综上所述，虽然使用cookie保持登录状态是一种简单易用的方法，但也存在诸多缺陷和风险。为了提高安全性和用户体验，开发者可以考虑采用其他技术手段，如Token机制，或者结合多种方法来实现更加安全和可靠的登录状态保持。
2. session:
相比cookie，用户信息是在服务端，高并发的场景下，服务端需要存储大量的session信息，占用空间比较大，一般sessionId是可以被获取到的。
拓展性：分布式场景下，两台服务器，其中一台保持了用户信息，当用户再请求时，分发到另一台服务器，这台没有用户信息，所以就不好。
3. token:
服务端根据一定的规则生成token，服务器会根据token，根据规则进行鉴权。
