作者：前端搬砖侠 Kincy
标签：全栈 / 登录态 / Cookie / JWT / 安全 / 社区精华收藏系列
💡 前言：登录只是开始，登录态才是灵魂
大家都知道，用户点了"登录"按钮之后，输入账号密码，然后你返回个 200 OK，就觉得万事大吉。
错！
真正的问题才刚刚开始：
- 用户怎么一直"保持登录"？
- 页面刷新了还在吗？
- 换个 Tab 会掉线吗？
- 后端要怎么知道这个请求是哪个用户发的？
- 如何优雅地"踢掉"小三账号？
今天我们就来聊聊前端人绕不开、后端人离不开、产品人根本不懂的东西------登录态的维持方案。
🍪 方案一：Session + Cookie ------"一刀切"式的古法保温
这套方案非常经典，像老中医一样，简洁靠谱。
🧠 工作原理
- 用户登录成功，后端生成一个
sessionId - 通过
Set-Cookie放进浏览器 - 之后浏览器每次请求自动带上 cookie
- 后端根据
sessionId从内存/Redis 里取出用户信息，嗯，有你了！
✅ 优点
- 超级安全！不泄露用户信息
- 支持强制下线、踢人、账号冻结
- 后端说了算！掌握全局控制权
❌ 缺点
- Session 存服务端，要么粘性负载，要么共享内存
- 架构一横向扩展，后端就一脸懵："我是谁？我在哪？"
🔥 方案二：JWT 无状态登录 ------"我不存你，但我认你"
现代派的代表人物：自带身份证的用户
🧠 工作原理
- 登录成功后，后端给你签发一个 Token，像张身份证
- 前端收到后，小心翼翼藏到 localStorage / sessionStorage 里
- 请求时加到
Authorization: Bearer xxx里发给后端 - 后端验证签名，一看对的，放行！
✅ 优点
- 后端无需存登录状态，天然支持微服务
- 横向扩展完全没问题，来几个实例都认你
- 签名机制安全性还不错，能防篡改
❌ 缺点
- 你掉了身份证（token 被泄露）？就等着被冒用吧
- 想让你"立刻下线"？不行，我后端不认"注销"这个词！
- 没有滑动过期，用户放一天不用就掉线了（体面点也不提醒一下）
🔁 方案三：JWT + Refresh Token ------"我能续命，我骄傲"
这一招来自高级玩家：Access Token + Refresh Token 双剑合璧
🧠 工作原理
- 登录时，给你两个 token：
- Access Token：活得短，干活多（几分钟过期）
- Refresh Token：活得久，藏得深（HttpOnly Cookie 中）
- Access Token 用来打工，请求接口
- 快过期了？用 Refresh Token 去刷新 Access Token，妥妥的续命机制
✅ 优点
- Access Token 就算被偷，攻击者也很快失效
- 后端可以控制 Refresh Token，有效"封号踢人"
- 用户无感刷新，体验丝滑顺畅
❌ 缺点
- 实现略复杂，要维护刷新接口、黑名单等
- 不用 Redis 都不好意思说自己搞过"撤销机制"
🥧 方案四：JWT in Cookie ------"我既要安全，也要自由"
如果你还在犹豫："localStorage 太不安全，Cookie 又怕被 CSRF 攻击"，那就试试 JWT 存 Cookie，策略配置满上！
🧠 推荐配置
text
Set-Cookie: token=xxx;
HttpOnly; Secure; SameSite=Strict; Max-Age=3600✅ 优点
HttpOnly防止 JS 访问（抵御 XSS）SameSite=Strict/Lax抵御 CSRF- 安全性与便捷性兼顾
❌ 缺点
- 跨域部署？麻烦来了，Cookie 不能跨域传，还得玩 CORS + withCredentials
- 搞不好就变成"我明明登录了，API 却说我没登录"系列灵异事件
📦 存储方式对比表
| 存储方案 | 安全性 | 跨域支持 | 自动携带 | 防御能力 | 推荐场景 |
|---|---|---|---|---|---|
| Cookie + HttpOnly | ✅ 高 | ❌ 麻烦 | ✅ 自动附带 | ✅ XSS / ✅ CSRF | SSR / 不跨域 |
| localStorage | ❌ 易被 JS 访问 | ✅ 跨域强 | ❌ 需手动加 | ❌ XSS / ❌ CSRF | 前后端分离 SPA |
| sessionStorage | ✅ 关闭即清除 | ✅ | ❌ | ✅ | 临时登录 |
| JWT + Refresh Token | ✅ 高 | ✅ | ❌（需代码实现） | ✅ 可控 | 多端 + 分布式架构 |
🕵️ 常见场景选型建议
| 场景 | 推荐方案 |
|---|---|
| 单体 SSR 项目 | Session + Cookie（简单高效） |
| 前后端分离项目 | JWT + Refresh Token（灵活安全） |
| 多端登录（Web+App） | JWT + Refresh Token + Redis 黑名单 |
| 企业级 SSO 系统 | OAuth2 / OIDC（统一认证） |
| 需要踢人下线、权限管控 | Session + Redis / JWT 黑名单 |
🧠 最后的建议（划重点！）
- 所有认证相关请求必须走 HTTPS
- Cookie 设置：
HttpOnly + Secure + SameSite - Access Token 要短、Refresh Token 要长、失效策略要精
- 别把 Token 丢 localStorage 然后说"我们系统很安全"
- 想省事但安全，就让浏览器自动帮你管 Cookie（配好策略）
🎯 写在最后
登录系统的设计，说白了就是"怎么信你还在线"，又"怎么防你被人冒名顶替"，前端后端架构全都绕不开。希望这篇文章能让你写登录时，不再是复制粘贴"JWT localStorage 一把梭"，而是真正理解每种方案的利与弊，做出更合适的选择。
👉 添加我的微信：JKfog233，邀你加入【Hello World 进阶群】，一起成长、交流、内推、分享机会！