扫码登录设计原理：扫码一笑，身份到手！

作者：Java开发第八年，Bug写得少了，需求改得多了，扫码登录也撸了三套半

前言：扫码登录，点亮中年程序员的社恐之光

你有没有经历过这种瞬间：

👨‍💻 手机在手，扫码一扫，网页自动跳转，登录成功，简直比女朋友的早安吻还准时。

而你作为一个资深 Java 开发，突然被 PM 拉过去问：

"扫码登录你来搞一下，微信那种。"

你心里一万个草泥马狂奔而过，表面却镇定地说："这简单，我这就写。"

那扫码登录到底怎么做？今天我们就从一个Java八年老猿 的角度，带你扫清扫码登录的原理迷雾。

一、扫码登录是个啥？先别装你没用过！

扫码登录，就是用户通过手机端扫码，然后在PC端完成登录。

比如：

你打开了PC上的某个网站，看到"扫码登录"；
拿出手机微信一扫；
手机跳出确认框：是否授权登录？
点"确认"，PC端直接登录。

整个过程不需要在PC端输入账号密码，体验丝滑得像海飞丝。

二、扫码登录=扫码+登录？别天真，那是地狱！

扫码登录的本质是：跨端认证授权。

背后的灵魂三问：

PC端怎么生成二维码？
手机扫码后怎么知道是哪台电脑要登录？
PC端如何知道手机那边确认了？

我们一一拆解。

三、扫码登录原理全流程（配合脑补图像）

Step 1：PC端生成二维码

PC端打开"扫码登录"页面，请求后端生成一个唯一的临时登录码（Login Token） ，比如 UUID。
后端将这个 Token 存入 Redis，状态为 waiting。
PC端拿到这个 Token，生成二维码，二维码内容是一个 URL，形如：

ini 复制代码

https://m.xxx.com/scan-login?token=abc123xyz

Step 2：手机扫码，发起登录请求

用户用手机微信/APP 扫码，实际上就是访问上面的 URL。
手机端访问后判断：用户是否登录了APP？
- 没登录就跳登录页面；
- 登录了就显示"是否允许登录此设备？"的授权页面。

Step 3：用户确认授权

用户点击"允许登录"；
手机端将该 Token 对应状态更新为 confirmed，并附带该用户的身份信息（userId）；
后端在 Redis 中更新 Token 状态：

json 复制代码

{
  "status": "confirmed",
  "userId": 9527
}

Step 4：PC端轮询 or WebSocket 拉状态

PC端每隔 2 秒请求一次后端接口（也可以用 WebSocket）：
- "喂喂，我这 Token 登了吗？"
后端查询 Redis：
- 如果 Token 状态还是 waiting，返回"还没确认"；
- 如果是 confirmed，返回 userId，同时创建登录态（Session/Cookie/JWT）；
- 然后把这个 Token 状态标记为 used，防止重复使用。

Step 5：PC端登录成功

PC端拿到用户身份，直接跳转首页，登录成功！

四、用嘴画个架构图（给面试官听）

lua 复制代码

+-------------+         +--------------+         +---------------+
|   PC端浏览器 | <--->   |   后端服务    | <---->  |   Redis缓存     |
+-------------+         +--------------+         +---------------+
       |                       ^
       |                       |
       |                       v
       |               +-----------------+
       |               |   手机APP扫码    |
       |               +-----------------+

PC端作为发起方，展示二维码；
手机端作为确认方，扫码并确认身份；
后端作为协调者，负责记录状态、验证身份；
Redis作为状态存储中转站，快、狠、准！

五、技术选型小贴士（Java党必看）

功能	技术选型
Token 生成	UUID / 雪花算法 / 自定义短码
状态存储	Redis（设置过期时间，避免垃圾Token）
移动端扫码	自定义 APP / 调微信扫一扫
通信方式	PC端建议用 WebSocket（实时，少轮询）
登录态创建	Spring Security + Session / JWT
安全校验	Token 状态校验、有效期、IP校验等

六、常见的"坑"，不踩才是老司机！

1. Token 被篡改了怎么办？

签名机制 / 加密；
Token 与 Redis 一一对应，如果 Redis 没有这 Token，拒绝操作。

2. 用户重复扫码怎么办？

Token 状态设置为 used，一旦登录成功就作废。

3. Token 不过期会怎样？

Redis 设置 TTL，比如 5分钟；
防止大量无效 Token 占用内存。

4. 用户扫码后不点确认？

一定要有倒计时提示；
不然你就等着被运营怼："转化率又掉了！"

七、面试时怎么装得像你写过5套扫码登录系统？

推荐回答模板如下，附带专业术语：

"我们扫码登录采用的是 Token + 状态轮询的形式。PC端页面请求后端生成临时登录码（存在 Redis），二维码中嵌入这个 Token。用户通过手机扫码后进入授权页面，确认后携带身份信息更新 Token 状态。PC端轮询 Redis 检查 Token 状态是否变为 confirmed，变更后建立登录态并销毁临时Token。整个流程通过 Redis 控制状态，避免Token重复使用，同时确保安全性与用户体验。"

💡 Bonus：

如果你说出"我们后面改成了 WebSocket 替代轮询，体验更丝滑"，面试官会当场点头像拨浪鼓。

八、总结：扫码一笑，身份到手，设计一套不掉头发

扫码登录看起来简单，实则是一个典型的跨端认证场景，涵盖了：

前后端分离的协同；
安全设计；
状态管理；
用户体验优化。

能搞懂扫码登录的原理，不仅能通过面试，还能带团队搞出高可用、高体验的登录系统。

别怕，你不是在扫码登录，你是在掌控身份的入口！