微信扫码登录是怎么运作的
你有没有遇到过这种情况：在电脑上打开某个网站，想登录却发现没带手机？或者记不住账号密码？这时候，微信扫码登录就派上用场了。点一下“用微信登录”，弹出一个二维码，拿出手机微信扫一扫，确认一下，秒登成功。整个过程不到十秒，方便得不行。但这个“扫一扫”背后，其实有一套完整的通信机制在跑。
第一步：网站生成临时二维码
当你点击“微信扫码登录”时，当前网站会向微信服务器发起请求，申请一个唯一的临时登录凭证。这个凭证通常是一个带编号的二维码，里面包含一串唯一ID，比如叫“login_token_abc123”。这个码不是固定的，每次刷新都会变，而且几秒后就会失效，防止被恶意利用。
你在网页上看到的那个二维码，本质上就是把这个唯一ID编码成图像，让微信能识别出来。
第二步：手机扫码，微信上报状态
你用手机微信扫一扫，摄像头解析出里面的唯一ID，然后微信客户端立刻拿着这个ID去问微信服务器：“有人扫了这个码，是哪个设备在登录？”服务器查到这个ID对应的是某网站的登录请求，于是记录下你的微信号和这个ID的绑定关系。
这时，你的手机微信会弹出一个确认框：“是否允许在‘XX网站’登录？”上面还显示设备型号、地理位置等信息。这一步很关键——你点了“确认”，才代表授权通过；要是不点，网页那边就一直卡在“等待扫码确认”。
第三步：网页轮询检查登录状态
在你扫码但还没确认的时候，电脑上的网页也没闲着。它每隔一两秒就偷偷问微信服务器一次：“那个ID的登录状态更新了吗？”这种反复询问的方式叫“轮询”（polling）。一开始服务器回：“未扫码”，后来变成“已扫码，待确认”，最后你一点确认，服务器就返回“已授权”。
一旦网页检测到“已授权”，它就会再向微信服务器请求你的公开用户信息，比如昵称、头像、地区等（不会拿到微信号或隐私数据），然后自动完成登录流程。
技术细节：前后端如何配合
网站前端页面通过 JavaScript 发起轮询请求，后端则负责和微信开放平台对接。微信提供了 OAuth2.0 接口，标准流程如下：
<!-- 网站获取二维码 -->
<img src="https://open.weixin.qq.com/connect/qrconnect?appid=YOUR_APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=snsapi_login" />
// 手机确认后，微信重定向到 redirect_uri，并带上 code
// 网站后端用这个 code 换取 access_token
GET https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
// 再用 access_token 获取用户基本信息
GET https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID整个过程中，用户的敏感信息始终掌握在微信手里，第三方网站只能获得授权范围内的公开数据，安全性有保障。
为什么这样设计更安全
传统账号密码登录，万一网站被黑，你的密码可能泄露。而扫码登录不需要输入任何凭证，登录动作发生在手机端，而手机本身已经是经过验证的可信设备。相当于把身份认证的“权力”交给了更安全的一方——你的微信App。
再加上二维码有效期短、一次性使用，即使被人截图，几秒后也失效了，风险极低。这种“反向验证”模式，现在也被很多平台模仿，比如钉钉、支付宝、甚至Steam都用了类似机制。
日常中的小细节
有时候你扫完码，手机没反应？可能是网络延迟，也可能是你误触关闭了确认弹窗。还有一种情况：网页提示“二维码已过期”，刷新一下就行，因为每个码只能用一次。如果你经常在家用电脑登录，会发现下次打开网站时，直接显示你的微信头像——这是浏览器存了登录态，不用重复扫码了。
这套机制既省事又安全，背后靠的是前后端协同、即时通信和权限控制的精密配合。下次你再“滴”一下扫码登录，就知道那一瞬间，已经跑了好几趟网络请求了。