Cookie、Session、Token详解
（一）Cookie：食堂给你的 “消费小纸条”
🌰 比喻：Cookie 就像食堂给你的 “消费小纸条”
- 每次你买饭菜（访问网站页面），食堂阿姨（服务器）会给你贴一张小纸条（Cookie），上面记着你买过啥菜系、上次消费金额
- 下次再去（再次访问网站），不用你说，食堂阿姨看小纸条（浏览器自动发 Cookie 给服务器），就知道给你推荐啥新菜，还能认出你是老顾客
💡 关键特点：
- 存在你手机 / 浏览器里（小纸条揣你兜里），能存简单信息（口味偏好、登录标记 ），但存太多会 “写不下”（容量小，一般 4KB 左右）
- 每次去食堂自动带（你揣着小纸条进出食堂），但别人能看见纸条内容（易被拦截篡改，得加 “防盗” 设置 ）
❓ 但 Cookie 有麻烦：
- 小纸条能被改：别人抢你小纸条（被黑客拦截），能改成 “你是 VIP” 骗阿姨；纸条也不能写太多字（Cookie 存不了复杂信息，一般就几 KB）
- 跨地儿不好使：你去食堂的其它分店（跨域访问其他网站服务），这纸条分店阿姨不认，得重新打交道
下面这张图就是实际的Cookie操作
（二）Session：你在食堂的 “专属储物柜”
🌰 比喻：Session 是你在食堂的 “专属储物柜”
- 第一次去食堂（登录网站），食堂前台（服务器）给你开一个储物柜（创建 Session），钥匙是个编号（Session ID），还把钥匙绑在你手腕带（Cookie 存 Session ID）
- 你把饭盒、常用餐具（购物车商品、个人信息 ）放储物柜（Session 存服务器），之后每次取东西（访问需要登录的页面），刷手腕带（发 Session ID），前台就知道开哪个柜子，拿你存的东西
💡 关键特点：
- 东西存在食堂（服务器），能存复杂信息（比 Cookie 能存更多、更敏感内容 ），但食堂得管好钥匙（服务器维护 Session 耗资源，连锁食堂 / 分布式系统里 “钥匙同步” 麻烦 ）
- 靠 Cookie 传钥匙（手腕带丢了，别人拿你钥匙就乱套，所以要防 Cookie 被盗 ）
❓ 为啥需要 Session：
- 藏好重要东西：饭卡、密码（敏感信息）放自己柜子（服务器），比塞纸条（Cookie 存敏感信息）安全多了！
- 能存更多内容：小柜子能塞下你一周的用餐习惯、收藏菜单（Session 存复杂信息，比 Cookie 能存更多）
但！要是食堂分店多（分布式系统，多个服务器），你在 A 店存的东西，B 店柜子里没有（Session 难跨服务器共享），还得专门搬数据（靠 Redis 等工具同步 Session），麻烦～
（三）Token：食堂给你的 “万能电子饭卡”
🌰 比喻：Token 是 “万能电子饭卡”，像手机里的二维码
- 第一次用 App 下单（登录系统），食堂发你个二维码（Token），上面加密写着 “你是学生，能打 8 折，能进教师食堂”
- 之后不管去食堂窗口、小卖部（访问不同服务），扫二维码（请求带 Token），阿姨（服务器）不用查柜子，直接扫二维码看权限（解析 Token 里的加密信息）
💡 为啥需要 Token：
- 跨地儿随便用：你去分校食堂（跨域、跨系统），二维码全国通用（Token 能跨平台、跨服务用），不用重新开柜子
- 不用共享状态：食堂不用记住你存啥（Token 无状态），扫一次码就知道你是谁、能干嘛，分店多也不怕（适合分布式系统）
举个🌰：你用手机点外卖（App 登录），去线下食堂刷脸（另一个服务），用同个 Token 就能认你身份，不用重新登录～
简单说：
- Cookie 是 “基础身份贴条”，但存不了太多、不安全；
- Session 把重要东西藏服务器，解决 Cookie 存敏感信息的问题；
- Token 让跨系统、跨平台 “认身份” 更方便，适合复杂、分布式的互联网应用～