🥷 前端老六上线了：登录成功后，我到底是怎么“一直在线”的？

作者：前端搬砖侠 Kincy

标签：全栈 / 登录态 / Cookie / JWT / 安全 / 社区精华收藏系列

💡 前言：登录只是开始，登录态才是灵魂

大家都知道，用户点了"登录"按钮之后，输入账号密码，然后你返回个 200 OK，就觉得万事大吉。

错！

真正的问题才刚刚开始：

• 用户怎么一直"保持登录"？
• 页面刷新了还在吗？
• 换个 Tab 会掉线吗？
• 后端要怎么知道这个请求是哪个用户发的？
• 如何优雅地"踢掉"小三账号？

今天我们就来聊聊前端人绕不开、后端人离不开、产品人根本不懂的东西------登录态的维持方案。

🍪 方案一：Session + Cookie ------"一刀切"式的古法保温

这套方案非常经典，像老中医一样，简洁靠谱。

🧠 工作原理

1. 用户登录成功，后端生成一个 sessionId
2. 通过 Set-Cookie 放进浏览器
3. 之后浏览器每次请求自动带上 cookie
4. 后端根据 sessionId 从内存/Redis 里取出用户信息，嗯，有你了！

✅ 优点

• 超级安全！不泄露用户信息
• 支持强制下线、踢人、账号冻结
• 后端说了算！掌握全局控制权

❌ 缺点

• Session 存服务端，要么粘性负载，要么共享内存
• 架构一横向扩展，后端就一脸懵："我是谁？我在哪？"

🔥 方案二：JWT 无状态登录 ------"我不存你，但我认你"

现代派的代表人物：自带身份证的用户

🧠 工作原理

1. 登录成功后，后端给你签发一个 Token，像张身份证
2. 前端收到后，小心翼翼藏到 localStorage / sessionStorage 里
3. 请求时加到 Authorization: Bearer xxx 里发给后端
4. 后端验证签名，一看对的，放行！

✅ 优点

• 后端无需存登录状态，天然支持微服务
• 横向扩展完全没问题，来几个实例都认你
• 签名机制安全性还不错，能防篡改

❌ 缺点

• 你掉了身份证（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，策略配置满上！

🧠 推荐配置

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 黑名单

🧠 最后的建议（划重点！）

1. 所有认证相关请求必须走 HTTPS
2. Cookie 设置：HttpOnly + Secure + SameSite
3. Access Token 要短、Refresh Token 要长、失效策略要精
4. 别把 Token 丢 localStorage 然后说"我们系统很安全"
5. 想省事但安全，就让浏览器自动帮你管 Cookie（配好策略）

🎯 写在最后

登录系统的设计，说白了就是"怎么信你还在线"，又"怎么防你被人冒名顶替"，前端后端架构全都绕不开。希望这篇文章能让你写登录时，不再是复制粘贴"JWT localStorage 一把梭"，而是真正理解每种方案的利与弊，做出更合适的选择。

👉 添加我的微信：JKfog233，邀你加入【Hello World 进阶群】，一起成长、交流、内推、分享机会！