登录鉴权这事，真没几个开发者搞明白。
Token、JWT、Session天天写，但改个登录逻辑就崩，查半天才发现在Redis里漏删了个key，或者JWT过期时间写成30天，用户登出后手机还能刷三天后台。
我上周帮公司重构登录模块，光是测登出场景就卡了四天——前端传错header，后端没校验token格式，Redis内存爆了没报警，全堆在生产环境才暴露。
这仨东西根本不是技术选型，是签合同。你跟客户端约好：我信你谁、信到什么时候、出了事怎么作废。签得清楚，系统就稳；签模糊了，一碰就炸。
Session是服务端记账。你一登录，服务器在Redis里给你开个户头，存你ID、角色、最后登录时间，再给你发个Session ID塞进Cookie。以后每次请求，浏览器自动带上，服务器翻账本核对。好处是HttpOnly关掉XSS偷不到，SameSite能防CSRF。但问题也很实在：App调不到Cookie，小程序不认Set-Cookie，负载均衡一换机器，账本就丢了。
Token（不是JWT，就是普通随机字符串）是服务端发信用凭证。你登录，服务器生成个UUID，存进Redis，附上用户ID和过期时间，返回给前端。下回带着它来，服务器查Redis里有没有、有没有被主动删。能登出、能踢人、用户信息不暴露。但说“无状态”是骗人的——Redis就是新状态中心。单机用内存缓存？一重启全丢。
JWT是客户端拿走的合约书。登录后服务器把用户ID、角色、时间戳打个包，用密钥签个名，直接发过去。以后服务器不存任何东西，靠签名验真假，靠时间戳看没过期。跨域没问题，小程序随便用，也不依赖Redis。但Payload是Base64，明文的，手机号、邮箱、权限列表全在里头，XSS一劫持，账号就归别人。更麻烦的是登出？删不了。只能设1小时有效期，再配个Refresh Token，但Refresh Token又得存Redis——绕一圈又回去了。
我们团队压测过：JWT在QPS 6000时，解析和验签吃掉32% CPU，比查Redis慢17ms；但Session在Redis故障时，5秒内掉12%请求；Token方案最稳，只要Redis不崩，登出秒生效，App和Web一套逻辑。
选哪个？先看能不能忍用户登出后还挂着账号。不能忍，JWT直接出局。再看客户端有哪些——只有网页？Session够用。有App、小程序、IoT设备？Session拜拜。接着看部署：三台机器？Session得搭Redis集群；五十个微服务跨机房？JWT省心。最后问自己：接口RT压到80ms以内，JWT那几十毫秒开销扛不住，就老老实实查Redis。
金融客户要审计，JWT的明文payload通不过，必须换Token或Session；开放平台给第三方调用？JWT还是标准，但过期时间砍到3600秒，登出走黑名单，别图省事。
我们最后选了GToken方案。登录发随机token，Redis存用户ID+时间戳+是否禁用，中间件自动校验。Web走header，App走query，小程序塞body，登出就是DEL命令。上线后登出平均响应23ms，Redis内存涨了不到1GB，没加新组件，运维不用学新东西。
JWT不是不好，是太“轻”了——轻到连作废都靠妥协。Session不是过时，是缩进了网页那块地。真正撑住中大型系统的，是那种服务端能管住、客户端能跑通、出事能立刻掐断的token。不是标准里写的，是日志里打出来的，是监控里盯出来的，是用户骂完之后你重发的那条修复补丁。
今天上线跑了六小时，零登录异常，登出全部生效，Redis没报警。
就这。
