会话 & 鉴权方式速查表

会话 & 鉴权方式速查表

2026-02-10项目分享1 阅读

会话 & 鉴权方式速查表

  • 能等过期 → 纯 JWT

  • 随时踢人 → Session + Redis

  • 多端混合 → JWT + RefreshToken

  • 教程/示例 → 常看到 JWT 存 Redis（历史包袱或路径依赖）

1. 背景速读

  • HTTP 天生无状态：每一次请求对服务器来说都是“陌生人”。

  • 会话机制就是给请求贴一张“身份证”，让服务器知道“你是谁、能干什么”。

  • 市面上主流做法只有 4 种，剩下都是它们的排列组合或包装。

2. 四种主流方案

| 名称 | 一句话解释 | 适用场景 | 爽点 | 痛点 |

| -------------------------------- | ------------------------------------------------------------ | ------------------------------------ | -------------------------------------- | ------------------------------------------------------------ |

| Session + Cookie（单机内存） | 浏览器口袋里只带“号码牌”，服务器抽屉里存全部资料 | 单体后台、内部系统 | 开发 5 分钟搞定；想踢人就删抽屉 | 服务器一重启，全员掉线；水平加节点=噩梦 |

| Session + Redis | 把抽屉搬到共享仓库（Redis），任何节点都能开抽屉 | 分布式集群、高并发网站 | 踢人秒级；扩容无感；Redis 挂了也有主从 | 多一次网络 IO；运维背锅；Redis 故障 = 全员下线 |

| 纯 JWT（无状态） | 把“你是谁+能干什么”直接写进 Token，服务器只认签名不记人 | 移动 App、小程序、Serverless、纯 API | 零存储；天然跨端；CDN/边缘函数直接验签 | Token 泄露=裸奔；无法实时踢人；体积随权限膨胀 |

| JWT + Redis 白名单/黑名单 | Token 还是 Token，但服务器额外在 Redis 里记一笔“这 Token 是否作废” | 想要 JWT 形态却必须踢人 | 既能水平扩容又能踢人 | 退化成“伪无状态”；每次请求都要查 Redis；写示例的人最多，用生产的人最纠结 |

3. 决策树（30 秒选对）

  1. 用户量 < 1 万，单机能扛？

  → Session + Cookie，下班早。

  1. 需要横向扩容，但运维有 Redis？

  → Session + Redis，稳。

  1. 多端（Web + App + 小程序）且团队小？

  → 纯 JWT，前后端一人搞定。

  1. 老板一句话“随时封号”？

  → 直接 Session + Redis 或 JWT + 黑名单，别纠结。

4. 常见误区辟谣

| 误区 | 真相 |

| ---------------------------- | ------------------------------------------------------------ |

| “JWT 一定比 Session 性能好” | 多一次签名验签，且 Token 体积更大；瓶颈在网络 IO 时差距可忽略 |

| “存 Redis 的 JWT 还是无状态” | 只要服务端查了 Redis，就是有状态，别再自欺 |

| “Cookie 不能用于移动端” | 可以，但得自己管理；JWT 放 Header 更直观，所以移动端倾向 JWT |

| “用了 JWT 就不用 HTTPS” | Token 一旦被抓包照样被重放，HTTPS 是底线 |

5. 一句话总结

Session 是“服务器记住你”，JWT 是“你自己带简历”。

选谁不取决于技术多潮，而取决于要不要实时踢人、要不要水平扩容、要不要跨多端。

本文由萧兮的博客原创发布，欢迎转载，转载务必保留原文链接。

萧兮的博客：https://www.20010515.xyz · 原文：https://www.20010515.xyz/posts/159dd954-f32d-44af-8a27-c229fb1d2a6e