扫码登录的核心是“状态轮询 + 临时凭证”，php仅生成带过期时间的加密ticket并供前端轮询，扫码行为由客户端完成，后端不主动监听；票据需存redis、绑定设备标识、防伪造、防遍历，轮询接口只查询不改状态，确认操作须原子化。
扫码登录的核心是“状态轮询 + 临时凭证”
PHP 本身不生成二维码，也不直接处理扫码动作；它只负责生成可被微信/支付宝等客户端识别的登录凭证（如 login_ticket），并提供一个接口供前端轮询该凭证是否已被扫描并确认。扫码行为发生在客户端（App 或小程序），PHP 后端只是被动响应。
常见错误是试图让 PHP 主动“监听手机扫码”，这不可能——http 是无状态短连接，PHP 进程不会常驻等待扫码事件。
- 必须用数据库或 Redis 存储临时登录票据，带过期时间（建议 5–10 分钟）
- 票据需绑定用户 ID（未登录时为空）、设备标识（如
device_id）、扫码状态（pending/scanned/confirmed） - 前端 js 每 2–3 秒调用一次
/api/login/poll?ticket=xxx，直到返回成功或超时
生成带参数的二维码链接要防伪造
二维码内容本质是一个 URL，比如 https://example.com/auth/scan?ticket=abc123。这个链接不能裸露暴露用户身份，也不能被重复利用。
关键点在于：ticket 必须是加密随机字符串（用 random_bytes(16) + bin2hex），且首次生成后立即写入 Redis，设置 EX 600（10 分钟过期）。
立即学习“PHP免费学习笔记（深入）”；
- 别用时间戳或自增 ID 做 ticket，容易被遍历
- URL 中不要携带
user_id、openid等敏感字段 - 如果走微信扫码登录，得调用微信 JS-SDK 的
wx.scanQRCode或后端调用qrconnect接口获取ticket，和自己生成的逻辑不同，注意区分场景
轮询接口必须做幂等和并发保护
前端可能因网络抖动多次发起同一 ticket 的轮询请求，后端若每次查库都触发状态更新，会导致逻辑错乱（比如把 scanned 错标成 confirmed）。
典型错误：在 GET /api/login/poll 里直接执行 UPDATE login_ticket SET status='confirmed' WHERE ticket=? —— 没有判断当前状态，也没加 where 条件锁。
- 轮询接口只做查询，不改状态；状态变更由扫码回调（如微信的
/wechat/callback）或确认接口（如POST /api/login/confirm）触发 - 确认操作要用乐观锁或 Redis lua 脚本保证原子性，例如：
EVAL "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('SET', KEYS[1], ARGV[2], 'EX', ARGV[3]) else return 0 end" 1 ticket_key pending confirmed 600 - 返回给前端的数据必须包含明确状态码（如
{"status":"scanned","user_info":{"nick":"xxx"}}），避免前端靠 HTTP 状态码判断逻辑
微信扫码登录和自建扫码不是一回事
很多人搜“PHP 二维码登录”，实际想接入的是微信网页授权登录，但混淆了“微信官方扫码”和“自己画个二维码让用户扫”。这是两套体系。
微信扫码登录走的是 OAuth2.0 流程：GET /api/wechat/qrcode 返回微信提供的 url（形如 https://open.weixin.qq.com/connect/qrconnect?appid=xxx&redirect_uri=xxx&response_type=code），用户扫码后微信跳转你的 redirect_uri 并带上 code，你再用 code 换 access_token 和用户信息。
- 自己生成的二维码链接不能直接对接微信 OAuth，必须用它指定的域名和
connect/qrconnect接口 - 微信要求
redirect_uri必须在公众号后台配置，且协议、域名、路径都要完全一致，否则报错redirect_uri 参数错误 - 调试时注意：微信开发者工具里的“扫码登录”模拟的是真实微信 App 行为，localhost 无法回调，得用 ngrok 或内网穿透
真正需要自建扫码逻辑的场景，通常是内部系统、iot 设备配网、或不想依赖第三方账号体系的情况。这时候所有链路都得自己控，也意味着所有安全细节——比如票据防重放、跨域限制、csrf 防护——都得手动补上。