本文原文链接
文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 ：
免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取
美团面试：手机扫描PC二维码登录，底层原理和完整流程是什么？
尼恩特别说明： 尼恩的文章，都会在 《技术自由圈》 公号 发布， 并且维护最新版本。 如果发现图片 不可见， 请去 《技术自由圈》 公号 查找
尼恩说在前面
在45岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团、蚂蚁、得物的面试资格，遇到很多很重要的相关面试题：
问题：M手机扫码登录，完整流程是什么？
最近有小伙伴面试美团 问到此 面试题。 小伙伴没有系统的去梳理和总结，所以支支吾吾的说了几句，面试官不满意，面试挂了。
所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V175版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取
那么手机扫码登录是如何实现的呢？45岁老架构师尼恩，带大家一步一步分析，深入分析 手机扫码登录的原理。
1、APP 登录和PC登录的原理
要理解 手机+PC配合， 扫码 登录原理，首先要理解 APP 登录和PC登录的原理
先看看 PC登录的原理
1.1 PC登录原理
PC端登录通常涉及用户输入账号和密码，服务器验证凭据并生成一个用于后续请求的身份验证令牌（token）。
详细和完整的PC登录流程：
详细和完整的PC登录流程，具体如下图：
PC登录流程，大致说明：
-
用户输入登录信息：
用户在PC端输入用户名和密码，点击登录按钮。
-
PC端发送登录请求：
PC端将用户名和密码发送到服务器的登录接口。
-
服务器验证用户名和密码：
服务器验证用户名和密码是否正确。
如果验证失败，返回错误提示。
如果验证成功，生成一个token并返回给PC端。
-
PC端存储token：
PC端接收到token后，将其存储在本地 localStorage、或者 sessionStorage或Cookie中）。
-
PC端发起请求：
用户在PC端进行操作，客户端向服务器发送请求。
请求中包含token，通常放在HTTP Header的
Authorization字段中。 -
服务器验证token：
服务器从请求中提取token并验证其有效性。
如果token无效，返回401 Unauthorized错误。
如果token有效，处理请求并返回响应。
-
服务器返回响应：
服务器处理完请求后，返回相应的响应。
PC端根据响应内容更新页面或提示用户。
步骤1：用户输入登录信息
用户操作：
用户在PC端的浏览器中打开登录页面。
用户输入用户名和密码，并点击“登录”按钮。
前端处理：
前端页面通过表单收集用户输入的用户名和密码。
前端可以对输入进行基本验证（如检查用户名和密码是否为空）。
前端将用户名和密码封装到一个请求中，通常是一个POST请求，发送到服务器的登录接口。
步骤2：服务器验证登录信息
接收请求：
服务器接收到登录请求，解析请求中的用户名和密码。
服务器通常会对请求进行安全检查，例如防止SQL注入、XSS攻击等。
验证凭据：
服务器查询数据库，检查用户名是否存在。
如果用户名存在，服务器会比对存储的密码（通常是加密后的密码）与用户输入的密码是否匹配。
如果用户名或密码不正确，服务器返回错误信息，例如“用户名或密码错误”。
如果用户名和密码验证通过，服务器会生成一个唯一的身份验证令牌（token），通常是一个JWT（JSON Web Token）或类似的令牌。
生成token：
服务器生成token时，会包含用户的基本信息（如用户ID、角色等），并设置token的过期时间。
服务器将token返回给客户端，通常通过HTTP响应的Body或Header返回。
步骤3：客户端接收token
接收响应：
PC端客户端接收到服务器返回的响应，从中提取token。
客户端通常会将token存储在本地，例如存储在浏览器的localStorage、sessionStorage或Cookie中。
存储token：
客户端存储token时，需要考虑安全性。例如，存储在HttpOnly的Cookie中可以防止XSS攻击，但需要确保Cookie的传输仅限于HTTPS。
客户端存储token后，会将token用于后续的请求，以验证用户的身份。
步骤4：客户端携带token访问服务器的业务接口
发起请求：
用户在PC端进行操作，客户端需要向服务器发送请求。
客户端在每个请求的HTTP Header中添加一个Authorization字段，值为Bearer <token>，将token发送到服务器。
服务器验证token：
服务器接收到请求后，从Authorization字段中提取token。
服务器验证token的有效性，包括检查token是否过期、签名是否正确、用户是否被禁用等。
如果token无效，服务器返回401 Unauthorized错误，提示用户重新登录。
如果token有效，服务器处理请求，并返回相应的响应。
步骤5：服务器 业务接口 返回响应
处理请求：
服务器根据请求的内容进行处理，例如查询数据库、执行业务逻辑等。
服务器在处理请求时，可以根据token中的用户信息（如用户ID）来确定用户的权限和操作范围。
返回响应：
服务器处理完请求后，将结果封装到HTTP响应中返回给客户端。
客户端接收到响应后，根据响应内容更新页面或提示用户。
1.2 APP 登录原理
APP 登录通常涉及用户输入账号和密码，服务器验证凭据并生成一个用于后续请求的身份验证令牌（token）。
详细和完整的APP登录流程：
详细和完整的APP 登录流程，具体如下图：
步骤1：用户输入登录信息并携带设备信息
-
用户操作：
用户在手机客户端上输入账号和密码。
手机客户端收集设备信息，如设备型号、操作系统版本、IP地址、设备唯一标识符（如IMEI、IDFA等）。
-
客户端处理：
手机客户端将用户名、密码和设备信息封装到一个请求中，通常是一个POST请求，发送到服务器的登录接口。
步骤2：服务器验证登录信息
-
接收请求：
服务器接收到登录请求，解析请求中的用户名、密码和设备信息。
-
验证凭据：
服务器查询数据库，检查用户名是否存在。
如果用户名存在，服务器比对存储的密码（通常是加密后的密码）与用户输入的密码是否匹配。
如果用户名或密码不正确，服务器返回错误信息，例如“用户名或密码错误”。
-
生成token：
如果用户名和密码验证通过，服务器生成一个唯一的身份验证token。
服务器将设备信息与token关联，存储在服务器的数据库或缓存中（如Redis），并设置token的过期时间。
-
返回响应：
服务器将token返回给手机客户端。
步骤3：手机客户端使用token 访问 服务器的业务接口
-
客户端携带token和设备信息请求：
手机客户端在每个请求的HTTP Header中添加
Authorization字段，值为Bearer <token>。有的时候，还带着设备 device-id 。请求示例：
GET /api/user_info Authorization: Bearer token-1234567890 X-Device-ID: device-id-1234567890 -
服务器验证token和设备信息：
服务器从请求中提取token和设备信息。
服务器验证token的有效性，包括检查token是否过期、签名是否正确。
如果token有效，服务器可以进一步验证，比如，设备信息是否与之前登录时的设备信息一致。
如果设备信息不匹配，服务器拒绝请求，并返回错误信息，例如“设备验证失败”。
-
服务器的 处理请求并返回响应：
如果token和设备信息验证通过，服务器处理请求，并返回相应的响应。
响应示例：
{"code": 200,"data": {"userId": "user-id-1234567890","username": "username","email": "user@example.com"} }
1.3 手机+PC配合， 扫码 登录原理
了解了 单独的 手机登录 和 PC端登录的原理后，理解手机+PC配合 扫码登录的原理就很简单了，
手机扫码登录的实质是通过已经在APP上登录的用户，帮助PC端的应用到服务器上申请pc-token，拿到pc-token后就和PC端登录服务器的原理一样了。
2 手机+PC配合 扫码 登录的完整流程
手机+PC配合 扫码 ， 主要分为三个阶段，待扫描阶段、已扫描待确认阶段、确认阶段。
-
待扫描阶段：
用户访问 PC 端，生成并显示二维码。
PC 端轮询二维码状态，等待用户扫描。
-
已扫描待确认阶段：
用户使用手机扫描二维码，服务器更新状态为“已扫描”。
PC 端显示“已扫描待确认”状态。
-
确认阶段：
用户在手机端确认登录，服务器生成登录凭证。
PC 端轮询到状态变化，完成登录流程。
2.1 APP+手机扫码 第一阶段：待扫描阶段
第一阶段： 待扫描阶段主要是生成二维码并展示给用户，属于PC端与服务器的交互。 第一阶段 包括两个步骤：
第一阶段：待扫描阶段 的时序图
步骤1：用户登录网页端，选择扫码登录
此时客户端会向服务端发送获取登录二维码的请求，服务端收到请求后，会随机生成一个唯一的二维码ID(UUID)，会将二维码ID、二维码ID的信息绘制成的二维码图片，一并返回给客户端。
步骤2：PC端 和 Server 进行状态同步
PC端 和 Server 建立 WebSocket 链接，服务器发送用户操作的状态给 PC端，状态包括： 二维码是否已扫描、用户是否已登录、二维码是否已过期 等。
当然，也可以反过来：PC端 启动一个定时器，通过轮询的方式向服务器发送请求确认二维码是否已扫描、用户是否已登录、二维码是否已过期。
第一阶段：待扫描阶段 的流程图
步骤1：用户请求扫码登录
-
用户操作：
用户在PC端浏览器中打开 APP（如 美团APP、微信APP等）。
用户点击“扫码登录”按钮，选择使用手机扫码的方式进行登录。
-
客户端请求：
PC端客户端向服务器发送一个HTTP请求，请求获取登录二维码。
请求中通常包含用户的基本信息（如浏览器指纹、IP地址等），用于后续的安全验证。
步骤2：服务器生成二维码
-
生成唯一二维码ID：
服务器接收到请求后，随机生成一个唯一的二维码ID（通常使用UUID）。
二维码ID作为登录会话的唯一标识，用于后续的扫码验证。
-
存储二维码信息：
服务器将二维码ID及其相关信息（如创建时间、过期时间、扫码状态等）存储在缓存系统（如Redis）中。
设置二维码的过期时间（例如5分钟），过期后二维码将失效，用户需要重新获取。
-
生成二维码图片：
服务器将二维码ID和相关信息绘制成二维码图片。
二维码图片可以由后端生成并返回Base64编码给前端，也可以将二维码ID返回给前端，由前端使用第三方库（如QRCode.js）生成二维码图片。
-
返回响应：
服务器将二维码ID、二维码图片（或Base64编码）、过期时间等信息返回给PC端客户端。
响应示例：
{"code": 200,"data": {"qrId": "uuid-1234567890","qrImage": "data:image/png;base64,iVBORw0KGgo...","expiresIn": 300} }
步骤3：PC端展示二维码
-
展示二维码：
PC端客户端接收到服务器返回的二维码图片后，将其展示在登录页面上。
同时，客户端会显示一个提示信息，告知用户使用 APP （如 美团APP、微信APP等）扫描二维码进行登录。
-
启动定时器：
PC端客户端启动一个定时器，通过轮询的方式向服务器发送请求，确认二维码是否已被扫描、用户是否已登录、二维码是否已过期。
定时器的轮询间隔通常为2-5秒。
请求示例：
GET /api/check_qr_status?qrId=uuid-1234567890
-
处理轮询响应：
服务器根据二维码ID查询缓存中的状态信息，并返回相应的状态码。
响应示例：
{"code": 200,"status": "pending" // pending: 待扫描, scanned: 已扫描, expired: 已过期, logged_in: 已登录}
第一阶段：待扫描阶段 注意事项
-
二维码ID存储：
二维码ID可以作为key值存入Redis中，同时设置过期时间和扫码状态。
若二维码过期，客户端可以提示用户刷新二维码，重新获取。
-
二维码生成方式：
可以将二维码ID和过期时间返回给前端，让前端自己生成二维码图片。
也可以由后端生成二维码图片并返回Base64编码给前端，减少前端的计算负担。
-
安全性：
二维码ID应具有足够的随机性和唯一性，避免被恶意猜测。
服务器应对接收到的请求进行安全验证，防止CSRF攻击。
2.2 APP+手机扫码 第二阶段：已扫描待确认阶段
第二阶段：待扫描阶段 的时序图
APP+手机扫码 第二阶段：已扫描待确认阶段 属于移动端与服务器的交互。
APP+手机扫码 第二阶段： 包括了4个步骤：
步骤1：APP 扫描二维码
用户打开移动端 APP（如 美团APP、微信APP等）扫描二维码，获取二维码ID，然后将手机端的登录的凭证(token)和二维码ID作为参数请求服务端。
步骤2：服务端生成临时 token
服务端收到请求后，会校验token，校验成功后，变更二维码的状态为已扫描，同时将 token 与二维码ID关联，然后生成一个临时 token(用于确认登录的凭证)，可以将临时 token和二维码ID存入到Redis中，并将该token会返回给移动端。
步骤3：用户在手机端确认是否登录
PC端的定时器，会轮询到二维码状态已经发生变化，会将PC端的二维码状态更新为已扫描待确认状态，并让用户在手机端确认是否登录。
步骤4：PC端更新二维码状态
PC端客户端通过定时器轮询服务器，检查二维码的状态是否发生变化。
如果二维码状态更新为“已扫描待确认”，PC端将二维码状态更新为“已扫描待确认”，并提示用户在手机端确认登录。
PC端显示提示信息，告知用户已有人扫描二维码，等待用户在手机端确认。
第二阶段：已扫描待确认阶段 的流程图
第二阶段：已扫描待确认阶段
该阶段主要涉及移动端与服务器的交互，确保用户在移动端确认登录操作。以下是更加细致和清晰的流程描述：
步骤1：移动端扫描二维码
-
用户操作：
用户打开 APP（如 美团APP、微信APP等），进入“扫一扫”功能。
用户将手机摄像头对准PC端显示的二维码，APP自动识别二维码并解析出二维码ID。
-
移动端请求：
移动端APP获取到二维码ID后，从本地获取当前用户的登录凭证（如token）。
移动端APP向服务器发送一个HTTP请求，请求中包含二维码ID和用户的登录凭证（token）。
请求示例：
POST /api/scan_qrContent-Type: application/json{"qrId": "uuid-1234567890","token": "user-token-1234567890"}
步骤2：服务端生成临时 token
-
校验token：
服务器接收到请求后，首先校验用户提供的token是否有效。
如果token无效，返回错误信息，提示用户重新登录。
-
更新二维码状态：
如果app token校验成功，服务器将二维码的状态从“待扫描”更新为“已扫描待确认”。
服务器将用户app token与二维码ID关联，并生成一个临时的token（用于确认登录的凭证）。
将临时token和二维码ID存入Redis中，并设置过期时间（例如5分钟）。
响应示例：
{"code": 200,"data": {"tempToken": "temp-token-1234567890"}}
-
返回临时token：
服务器将生成的临时token返回给移动端APP。
步骤3：用户在手机端确认是否登录(移动端显示确认提示)
-
移动端接收响应：
移动端APP接收到服务器返回的临时token后，显示一个确认登录的提示。
提示用户是否确认在PC端登录，提供“确认”和“取消”选项。
-
发送登录提醒通知：
移动端APP可以向用户发送一条登录提醒通知，提醒用户有新的登录请求。
如果用户确认不是本人操作，建议用户立即修改密码。
步骤4：PC端更新二维码状态
-
PC端轮询状态：
PC端客户端通过定时器轮询服务器，检查二维码的状态是否发生变化。
如果二维码状态更新为“已扫描待确认”，PC端将二维码状态更新为“已扫描待确认”，并提示用户在手机端确认登录。
-
显示提示信息：
PC端显示提示信息，告知用户已有人扫描二维码，等待用户在手机端确认。
注意事项
-
用户确认的目的：
让用户确认的目的是防止其他人拦截token冒充登录。通过用户主动确认，确保登录操作的安全性。
-
登录提醒通知：
扫码后点击确认后，可以向用户APP或手机等设备发送登录提醒通知。
如果不是本人登录，建议用户立即修改密码。
-
安全性：
临时token应具有足够的随机性和唯一性，避免被恶意猜测。让用户确认的目的，是防止其它人拦截token冒充去登录。
服务器应对接收到的请求进行安全验证，防止CSRF攻击。
通过以上步骤，已扫描待确认阶段的流程更加清晰和详细，确保了用户在移动端能够安全地确认登录操作。
手机扫码登录 主要分为三个阶段，待扫描阶段、已扫描待确认阶段、已确认阶段。请完善一下下面的第三阶段：已确认阶段，要求更加细致， 流程更加清晰 ， 待扫描阶段 的大致介绍如下：
2.3 APP+手机扫码 第三阶段： 已确认阶段
该阶段主要涉及移动端与服务器的交互，以及PC端的状态更新，确保用户在移动端确认登录后，PC端能够顺利获取正式的登录凭证并完成登录。
第三阶段：待扫描阶段 的时序图
步骤1：临时token =》pc token
用户点击确认登录后，移动端携带之前服务端发送的临时token访问服务端，服务端校对完成后，会拿到二维码的ID，同时更新二维码状态为已确认，并给PC端生成一个正式的pc token，该token和用户信息(例如用户ID)可以组合在一起存到Redis中，同时将临时token从Redis中删除，后续PC端通过此正式token与服务端进行交互。
步骤2：服务器处理确认请求
PC端的定时器，会轮询到二维码状态已经发生变化，同时拿到PC端正式token。
步骤3：服务端 通知PC端
步骤4：PC端完成登录后的正式访问
第三阶段：已描待确认阶段 的流程图
步骤1：移动端确认登录
-
用户操作：
用户在移动端APP中点击“确认登录”按钮。
-
移动端请求：
移动端APP携带之前服务器发送的临时token，向服务器发送确认登录请求。
请求示例：
POST /api/confirm_loginContent-Type: application/json{"tempToken": "temp-token-1234567890"}
步骤2：服务器处理确认请求
-
校验临时token：
服务器接收到请求后，首先校验临时temp-token是否有效。
如果临时temp-token无效或已过期，返回错误信息，提示用户重新扫描二维码。
-
更新二维码状态：
如果临时temp-token校验成功，服务器将二维码的状态从“已扫描待确认”更新为“已确认”。
服务器根据二维码ID获取用户信息（如用户ID）。
-
生成正式token：
服务器为PC端生成一个正式的登录pc token。
将正式token和用户信息（如用户ID）组合在一起存入Redis中，并设置过期时间（例如1小时）。
同时，从Redis中删除临时token。
-
返回响应：
服务器将正式pc token返回给移动端APP。
响应示例：
{"code": 200,"data": {"pcToken": "pc-token-1234567890"}}
步骤3：服务端 通知PC端
-
移动端接收响应：
移动端APP接收到服务器返回的正式pc token后，不需要进行额外操作，但可以提示用户登录已成功。
-
PC端轮询状态：
服务端推送模式下：服务端 通知PC端二维码状态更新为“已确认”，把 pc token 推送给 PC端。
客户端 轮询模式下：PC端客户端通过定时器轮询服务器，检查二维码的状态是否发生变化。如果二维码状态更新为“已确认”，PC端从服务器拿到 正式的登录pc token。
-
PC端更新状态：
PC端客户端接收到正式token后，更新登录状态，提示用户登录成功。
PC端客户端可以使用正式token与服务器进行后续的交互。
步骤4：PC端完成登录后的正式访问
-
PC端使用正式pc token：
PC端客户端使用正式token向服务器发送请求，获取用户信息并完成登录。
请求示例：
GET /api/user_infoAuthorization: Bearer pc-token-1234567890
-
服务器返回用户信息：
服务器验证正式token，返回用户信息。
响应示例：
{"code": 200,"data": {"userId": "user-id-1234567890","username": "username","email": "user@example.com"}}
-
PC端显示用户信息：
PC端客户端接收到用户信息后，显示用户登录后的界面，完成登录流程。
注意事项
-
安全性：
临时token和正式 pc token应具有足够的随机性和唯一性，避免被恶意猜测。
服务器应对接收到的请求进行安全验证，防止CSRF攻击。
扫码之后点击确认之后，可以往用户app或手机等设备发送登录提醒的通知，若不是本人登录，建议用户立即修改密码。
-
用户体验：
在移动端和PC端都应提供清晰的提示信息，确保用户知道每一步的操作结果。
如果用户在移动端取消确认，服务器应将二维码状态重置为“待扫描”，并提示用户重新扫描。
-
错误处理：
如果在确认过程中出现错误（如临时token过期、网络问题等），应提供明确的错误提示，并引导用户重新操作。
通过以上步骤，已确认阶段的流程更加清晰和详细，确保了用户在移动端确认登录后，PC端能够顺利获取正式的登录凭证并完成登录。
3：二种 通信模式的 总结：
二维码的状态变更，涉及到服务器和客户端之间的通信问题，有二种实现方案， 或者二种模式。
45岁老架构师尼恩给大家来一个 模式大总结：
模式1：长连接模式（如websocket）：
长连接模式，服务端可以主动推送，所以也叫做服务端推送模式。 在这个模式下，服务端 通知PC端二维码状态更新。
模式2：短连接模式（如http）：
短连接模式，也叫做 客户端 轮询模式，
在客户端 轮询模式下，PC端客户端通过定时器轮询服务器，查询二维码的状态。
4：登录涉及的 3个token的 总结：
手机+PC配合 扫码 登录的完整流程，涉及到3个token.
45岁老架构师尼恩给大家来一个 3个token大总结：
4.1. 手机端登录凭证（token）
来源：用户在移动端 APP 登录时，由服务器生成并发放给移动端，用于标识用户在移动端的登录身份。
作用：在移动端扫描二维码后，移动端 APP 将该 token 与二维码 ID 一起发送给服务器，服务器通过校验此 token 来确认移动端用户的身份是否合法。
生命周期：在用户移动端 APP 登录期间有效，直到用户主动退出登录或 token 过期。
作用：用于移动端APP的用户身份验证。用于移动端APP与服务器进行交互，执行业务操作。
存储位置：用户Token存储在移动端设备上，通常存储在本地存储（如localStorage、sessionStorage或Cookie）中。
过期时间：通常较长，例如1小时或更长。
安全性：用户Token具有足够的随机性和唯一性，避免被恶意猜测。同时，服务器会验证Token的有效性，包括检查Token是否过期、签名是否正确。
4.2. 临时 token（用于确认登录的凭证）
来源：当服务器接收到移动端发送的二维码 ID 和手机端登录凭证（token），且校验手机端 token 成功后，服务器生成临时 token。
生成时间：在已扫描待确认阶段，当移动端扫描二维码后，服务器生成临时Token。
手机扫码登录中核心是, 已在APP上登录的用户, 使用APP帮助PC客户端拿到服务器颁发的pc-token来实现PC端的登录
用户在手机上点击确认登录后, 会发送一个携带临时temp token的请求到服务器上，服务器验证临时token是否有效，如果临时token是有效的，服务器就会生成一个pc-token以及修改二维码的状态为登录状态的一系列操作。
作用：作为用户在APP 确认登录 PC 端的临时凭证，APP 携带该临时 token 向服务器发送确认登录请求，服务器通过校验临时temp- token 来确认是用户本人在移动端进行了确认登录操作。
生命周期：通常有较短的过期时间（如 5 分钟），在确认登录流程完成后会从 Redis 中删除。
temp- token 作用：
-
用于标识移动端的扫码操作。
-
用于移动端向服务器确认登录请求。
存储位置：temp- token 存储在服务器的缓存系统（如Redis）中，与二维码ID关联。
- 过期时间：通常较短，例如5分钟。
- 安全性：临时Token具有足够的随机性和唯一性，避免被恶意猜测。
4.3. 正式的 PC token
来源：服务器在校验临时 token 成功后，为 PC 端生成正式的登录 pc token。
作用：PC 端使用该正式 token 与服务器进行后续的交互，如获取用户信息等，标识 PC 端用户的登录状态。
生命周期：有相对较长的过期时间（如 1 小时），在有效期内 PC 端可以凭借此 token 正常访问服务器资源，直到 token 过期或用户退出登录。
生成时间：在已确认阶段，当用户在移动端确认登录后，服务器生成正式PC Token。
PC token作用：
- 用于PC端后续的请求，验证用户身份。
- 用于PC端与服务器进行交互，获取用户信息和执行业务操作。
存储位置：正式PC Token存储在服务器的缓存系统（如Redis）中，与用户信息（如用户ID）关联。
过期时间：通常较长，例如1小时。
安全性：正式PC Token具有足够的随机性和唯一性，避免被恶意猜测。同时，服务器会验证Token的有效性，包括检查Token是否过期、签名是否正确。
4.4: 3个Token的流程总结
-
待扫描阶段：
PC端请求服务器生成二维码。
服务器生成二维码ID和二维码图片，返回给PC端。
PC端展示二维码，并启动定时器轮询服务器，查询二维码状态。
-
已扫描待确认阶段：
移动端扫描二维码，获取二维码ID。
移动端向服务器发送二维码ID和用户Token。
服务器验证用户Token，生成临时Token，更新二维码状态为“已扫描待确认”。
服务器将临时Token返回给移动端。
PC端通过轮询或WebSocket接收到二维码状态更新，提示用户在手机端确认登录。
-
已确认阶段：
用户在移动端确认登录。
移动端向服务器发送临时Token。
服务器验证临时Token，生成正式PC Token，更新二维码状态为“已确认”。
服务器将正式PC Token返回给PC端。
PC端使用正式PC Token与服务器进行后续的交互，完成登录。
说在最后：有问题找老架构取经
只要按照上面的 尼恩团队梳理的 方案去作答， 你的答案不是 100分，而是 120分。面试官一定是 心满意足， 五体投地。
按照尼恩的梳理，进行 深度回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。
很多小伙伴刷完后， 吊打面试官， 大厂横着走。
在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。
另外，如果没有面试机会， 可以找尼恩来改简历、做帮扶。
前段时间，刚指导一个小伙 暴涨200%（涨2倍），29岁/7年/双非一本 ， 从13K一次涨到 37K ，逆天改命。
另外，刚指导一个 40岁大龄，上岸：转架构，收3个外企offer， 机会多了，不焦虑了，逆天改命。
狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。
技术自由的实现路径：
实现你的 架构自由：
《吃透8图1模板，人人可以做架构》
《10Wqps评论中台，如何架构？B站是这么做的！！！》
《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》
《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》
《100亿级订单怎么调度，来一个大厂的极品方案》
《2个大厂 100亿级 超大流量 红包 架构方案》
… 更多架构文章，正在添加中
实现你的 响应式 自由：
《响应式圣经：10W字，实现Spring响应式编程自由》
这是老版本 《Flux、Mono、Reactor 实战（史上最全）》
实现你的 spring cloud 自由：
《Spring cloud Alibaba 学习圣经》 PDF
《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》
《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》
实现你的 linux 自由：
《Linux命令大全：2W多字，一次实现Linux自由》
实现你的 网络 自由：
《TCP协议详解 (史上最全)》
《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》
实现你的 分布式锁 自由：
《Redis分布式锁（图解 - 秒懂 - 史上最全）》
《Zookeeper 分布式锁 - 图解 - 秒懂》
实现你的 王者组件 自由：
《队列之王： Disruptor 原理、架构、源码 一文穿透》
《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》
《缓存之王：Caffeine 的使用（史上最全）》
《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》
实现你的 面试题 自由：
4800页《尼恩Java面试宝典 》 40个专题
免费获取11个技术圣经PDF：
