核心是前后端协同维护可轮询的登录态绑定关系：Web端生成带过期时间的UUID二维码，App扫码解析后提交UUID与自身token完成绑定，Web端定时轮询状态直至成功或超时。
uni-app
实现网页端扫码登录、App 端联动，核心不是“调用
就完事”，而是前后端协同维护一个**可轮询的登录态绑定关系**。Web 端生成带唯一 ID 的二维码，App 扫码后提交该 ID + 自身用户凭证（如
），后端完成绑定，Web 端靠轮询感知结果——这才是稳定落地的链路。
Web 端怎么生成可轮询的二维码
关键不是渲染图片，而是生成一个能被 App 解析、且服务端能追踪的 payload。常见错误是直接把跳转链接塞进二维码，导致无法携带用户身份信息。
后端提供
接口，返回一个随机
（如
），并存入数据库，状态设为
Web 端用这个
拼出扫码内容：例如
，再用
生成图像
不要用纯 URL（如
）作为二维码内容——App 扫出来只是打开网页，无法自动回传 token
若需兼容 H5 直接扫码跳转，可加字段区分：
，App 端解析后走绑定逻辑，H5 端忽略或 fallback
App 端扫码后怎么提交登录请求
扫码拿到的是字符串，必须手动 JSON.parse，再提取
，不能假设它一定是 URL 或 base64。
调用
后，检查
是否为合法 JSON 字符串，用
包裹
确认含
字段且非空，否则提示“无效二维码”
发起绑定请求时，必须带上当前用户的认证凭据（如从
取出的 Bearer Token），后端靠它识别是谁扫的码
示例请求：
后端收到后，更新数据库中对应
记录的
和状态为
uni-app电商系统实战精讲课程课件
uni-app电商系统实战精讲课程
下载
Web 端怎么安全轮询登录结果
轮询不是无脑
，要控制频率、超时和终止条件，否则容易触发接口限流或白屏卡死。
建议初始间隔 1s，连续 3 次无响应后延长至 2s，最多轮询 60s（1 分钟）后自动失败
每次请求带
，后端查数据库：若状态为
，返回
；若为
，前端清空二维码并提示重试
一旦收到成功响应，立即
，保存
到
，跳转首页
注意：轮询请求需带
（若用 cookie 鉴权），但更推荐 token 放 header，避免跨域 cookie 问题
为什么不能直接用微信扫码登录替代这套流程
微信扫码登录（
）只适用于「网站应用」场景，且强制跳转微信域名、依赖用户已登录微信账号。而 uni-app App 端扫码登录的本质是「自有账号体系打通」，两者协议层不兼容。
微信扫码返回的是
→ 换
→ 换
，你拿不到 App 端当前登录用户的 ID
App 端若未集成微信 SDK，根本无法响应微信 redirect_uri 的跳转，
里扫码也受限于 iOS WKWebView 的跳转拦截
真正需要的是 App 身份“主动声明”：我（App 用户 A）扫了这个码，我要登录 Web 端——这只能靠自定义 UUID + token 绑定实现
最容易被忽略的一点：UUID 必须带过期时间（如 5 分钟），数据库字段加
，轮询接口和绑定接口都要校验。否则攻击者可长期重放旧二维码，伪造登录。
uni.scanCodetoken/api/generate-qrcodeuuid"a1b2c3d4-5678-90ef-ghij-klmnopqrstuv""pending"uuid{"type":"login","uuid":"a1b2c3d4-...","ts":1745483364}qrcodejs2https://example.com/login?code=xxx{"type":"login","uuid":"...","mode":"app"}uuiduni.scanCoderes.resulttry...catchJSON.parseuuiduni.getStorageSync('token')uni.request({
url: 'https://api.example.com/bind-login',
method: 'POST',
header: {
Authorization: 'Bearer ' + uni.getStorageSync('token')
},
data: { uuid: parsed.uuid }
})uuiduser_id"completed"setIntervaluuid"completed"{status:"success", user:{id:123, name:"xxx"}, token:"xxx"}"failed"clearIntervaltokenlocalStorageCredentials: "include"snsapi_logincodeaccess_tokenopenidweb-viewexpires_at