登录网站时输入账号密码，跳转页面后却不用重复登录；电商购物车里的商品，换设备登录依然在；APP里刷短视频，每次滑动都不用重新验证身份……这些“无缝衔接”的体验，背后藏着Web身份认证的三大核心工具：Cookie、Session、Token。它们像三把“安全钥匙”，各自有独特的“开锁逻辑”，用错场景可能让黑客有机可乘！今天就用大白话拆解它们的原理、区别和适用场景，看完秒懂如何“精准用锁”。
一、Cookie：浏览器里的“记忆卡片”
Cookie是服务器“塞”给浏览器的一小段文本，就像一张“身份便签”。当你登录网站时，服务器会生成一个包含用户ID的Cookie，浏览器收到后自动存储（默认2-4KB，可设置过期时间）。之后每次访问同一网站，浏览器都会自动带上这个Cookie，服务器通过它识别“你是谁”。
典型场景：
- 电商网站的“记住密码”功能（下次登录自动填充）；
- 购物车数据跨页面同步（即使跳转商品页，购物车里的商品依然在）；
- 广告精准推送（根据Cookie记录的浏览历史推荐商品）。
缺点：Cookie存储在浏览器，容易被篡改（比如修改用户ID伪造身份）；且依赖浏览器，移动端APP无法直接使用。
二、Session：服务器端的“身份档案柜”
Session是服务器为每个用户创建的“专属档案”，存储在服务端（比如内存、数据库）。当你登录时，服务器生成一个唯一的Session ID，通过Cookie返回给浏览器；浏览器后续请求带上这个ID，服务器从“档案柜”里找到对应的用户信息，完成身份验证。
典型场景：
- 银行网站登录后，所有操作（转账、查询）无需重复输入密码；
- 后台管理系统（比如CMS）的权限控制（不同角色看到不同菜单）。
优点：数据存储在服务端，安全性高（即使Cookie被窃取，没有服务端的Session数据也无法伪造身份）；缺点：用户量大时，服务端存储压力剧增（比如百万用户同时在线，需要维护百万份Session），可能影响性能。
三、Token：无状态的“加密令牌”
Token是服务器生成的“加密通行证”，通常包含用户ID、过期时间等信息，用算法（如JWT）签名防止篡改。用户登录后，服务器返回Token，浏览器存储在Cookie或本地（LocalStorage）；后续请求带上Token，服务器验证签名即可确认身份，无需再查“档案柜”。
典型场景：
- 移动端APP（微信、抖音）的身份认证（APP和服务器通过Token交互，不依赖浏览器）；
- 微服务架构（多个服务共享Token，避免每个服务都维护Session）；
- 跨域请求（Cookie有同源限制，Token可自由传递）。
优点：无状态（服务器不用存储Token，减轻压力）、跨平台（APP/Web/小程序通用）；缺点：Token一旦泄露无法撤销（只能等过期），需配合短有效期（如2小时）和刷新机制使用。
四、如何“精准用锁”？记住这3条原则！
- Web网站用Session+Cookie：需要强安全性的场景（如银行、后台管理），用Session存储用户数据，Cookie传递Session ID。
- 移动端/跨平台用Token：APP、小程序或需要跨域请求时，用Token（如JWT）实现无状态认证。
- 简单数据存储用Cookie：比如“记住密码”“语言偏好”等非敏感信息，可直接用Cookie存储（记得设置HttpOnly和Secure标志防窃取）。
Cookie、Session、Token没有“谁更好”，只有“谁更适合”。用对场景，才能让身份认证既安全又高效；用错场景，可能让黑客轻松“偷家”！下次开发或选型时，记得对照这篇文章“对号入座”哦~
