9. 如何实现一个扫码登录功能？

扫码登录的设计思路是通过Ticket关联PC与手机，通过 JWT 验证手机身份，通过长连接推送凭证，要点就两个：安全性和服务端推送。

下面，我们来展开讲解扫码登录的详细流程：

1. PC端：发起请求 → 展示二维码 → 监听登录状态

• 步骤1：请求生成二维码
  PC端向服务端发送「获取登录二维码」请求，携带PC端基础信息（如设备ID、浏览器UA，用于后续安全校验）。
• 步骤2：渲染二维码
  接收服务端返回的「唯一二维码标识（Ticket）」，将其拼接为URL（如 https://xxx.com/login/scan?ticket=xxx），通过前端库（如 qrcode.js）生成二维码并展示。
• 步骤3：监听登录状态
  采用「WebSocket长连接」（优于轮询，实时性高）向服务端持续查询该Ticket的状态（状态枚举：未扫码/已扫码待确认/已确认/已过期）。
• 步骤4：完成登录
  PC端通过WebSocket收到「登录成功」通知后，获取服务端推送的「登录凭证（Session/JWT）」，将其存入 Cookie或 localStorage（优先Cookie防XSS），随后跳转至首页，完成登录

2. 服务端：生成标识 → 管理状态 → 验证身份

• 步骤1：生成Ticket与存储状态
  收到PC端请求后，生成一个短期有效（如5分钟）、全局唯一的Ticket，并在缓存（如Redis）中初始化状态：
  • Key：scan_login:ticket:xxx
  • Value：{status: "unscanned", pcDeviceId: "xxx", createTime: "xxx"}
  • 过期时间：5分钟（防止二维码长期有效被滥用）。
• 步骤2：接收手机端验证请求
  手机端扫码后发起验证，服务端需做两件事：
  1. 校验手机端身份：验证手机端携带的「用户Token」是否有效（查询数据库/Redis确认Token归属与有效性）；
  2. 更新Ticket状态：若Token有效，将Redis中该Ticket的状态更新为 pending_confirm（已扫码待确认），并关联用户ID（如 userId: 123）。
• 步骤3：接收手机端确认请求
  手机端点击「确认登录」后，服务端再次校验Token，确认无误后：
  1. 更新Ticket状态为 confirmed（已确认）；
  2. 生成PC端登录凭证：创建PC端专属的Session（或JWT），关联用户ID，存入Redis/数据库；
  3. 缓存映射关系：将 Ticket 与 PC端登录凭证 绑定（供PC端后续获取）。
• 步骤4：向PC端推送结果
  通过WebSocket将「登录成功」状态与「PC端登录凭证」推送给PC端。

3. 手机端：扫码 → 验证 → 确认登录

• 步骤1：扫码解析信息
  手机端（已登录状态）通过扫码API（如微信小程序 wx.scanCode、APP原生扫码SDK）解析二维码中的URL，提取 token。
• 步骤2：发起验证请求
  向服务端发送「扫码验证」请求，携带 Ticket 和手机端的 JWT 。
• 步骤3：用户确认登录
  手机端收到服务端返回的「验证通过（待确认）」后，弹窗提示用户「是否允许PC端登录」，用户点击「确认」后，向服务端发送「确认登录」请求（同样携带 Ticket 和 Token）。

安全保障:

1. Ticket时效性：设置5分钟过期，过期后PC端需重新生成二维码。
2. 防重复使用：PC端获取登录凭证后，立即删除Redis中的Ticket，防止重复使用。
3. 设备绑定校验：服务端校验PC端设备ID与手机端常用设备是否匹配（如用户从未在该PC登录过，可增加二次验证）。
4. 通信加密：所有请求（PC→服务端、手机→服务端）必须走HTTPS，防止Ticket/Token被中间人窃取。
5. 防恶意扫码：若同一Ticket被多次扫码（如超过3次），直接标记为「异常」并失效，防止暴力攻击。

长连接推送的要点：

1. WebSocket 基于 TCP 协议，可能因网络波动、服务器重启等原因断开，需要心跳机制检测连接状态。
   1. 客户端定期（如 30 秒）向服务端发送 ping 帧（WebSocket 原生支持），服务端返回 pong 帧响应。若客户端连续多次未在时限内收到 pong 则判定为断线
   2. 首次断线后立即重试，失败后间隔 1s、2s、4s...（最多 8s）重试，避免短时间内大量无效请求冲击服务器。
   3. 重连时客户端需携带「唯一会话标识」（如用户 Token + 设备 ID），服务端通过标识从缓存（如 Redis）中恢复之前的会话状态（如未发送的消息、订阅频道），避免用户感知中断
2. 通常单服务器可支撑 10 万 - 50 万连接，当设备量超过单网关承载上限就需要通过多网关集群进行扩展。
   1. 部署多个 WebSocket 网关实例。
   2. 用户连接到哪个网关、订阅的频道等信息存入 Redis，如 user:123 → { gateway: "gateway1", channels: ["chat"] }。业务服务器需要向某个用户推送消息时先查 redis 取出网关信息，然后向对应的网关发送 rpc 请求即可。