用户扫码后手机点了确认，PC 登录页还停在转圈，先查轮询间隔还是先查二维码状态？

先给结论：PC 登录页停在等待，多数不是轮询间隔太长，而是二维码状态没写进去，或者取状态那条通道在客户网络里断了。扫码登录拆开只有两件事：一张带四态的票据（待扫描、已扫描待确认、已确认、已使用或已过期），加一条把状态变化送回浏览器的通道。按 2026 年常见交付经验，单端等待、秒级可接受时，1.5~3 秒带退避的短轮询配合状态版本号，就能把「手机点确认到网页跳转」压在 1~3 秒经验区间；只有多端同时等待、或要求亚秒级反馈，换长轮询、SSE、WebSocket 才划算。排查顺序也随之固定：先看服务端状态对不对，再看通道通不通，最后才谈间隔调多少。

一、卡在等待页时，先分清是状态没写进去还是通道断了

两种卡法表现一模一样，处理方式却完全不同。交付里更常见的是前者：确认接口被条件更新挡回去、票据签发失败、手机端根本没把确认请求发出去。通道问题则集中在几类固定环境上——反向代理掐空闲连接、升级请求被中间设备拦掉、跨域没带凭据。

分辨办法很土但有效：拿这张 ticket 直接查一次服务端记录。已是「已确认」，说明状态写进去了，问题在通道或前端换票据那一步；仍是「已扫描待确认」，说明确认请求没生效；显示「已使用」，多半是同一人开了多个页面，或这张码被截图转发后别人先用掉了。

• 已确认、页面不动：查轮询是否还在发、长连接是否已被降级、换登录态时是否被跨域凭据挡住。
• 仍是待扫描：查确认接口的条件更新条件和返回码，别只看前端有没有弹成功提示。
• 已使用：查多标签页或抢码，此时调间隔没有意义。

二、四态状态机定不死，通道怎么调都白搭

四个状态各自的写入方必须写清楚，一个状态只允许一个入口去推：生成码时写「待扫描」，只有手机扫码接口能推到「已扫描待确认」，只有手机确认接口在校验当前状态仍为「已扫描」时才能推到「已确认」，只有浏览器凭一次性票据换登录态时才推到「已使用」。写入方一乱，后面调什么间隔都是白费。

• 待扫描：ticket 落库并带有效期，常见 60~120 秒经验区间；过期即作废，前端要能一键换新码。
• 已扫描待确认：更新带条件（当前状态仍为待扫描），避免并发互相覆盖，也避免旧请求把新状态打回去。
• 已确认：签发一次性登录票据，与 ticket 绑定，只允许消费一次。
• 已使用或已过期：消费后立刻置为已使用，重复消费直接拒绝，挡住截图转发和重放。

状态里再加一个自增版本号，取状态接口连版本号一起返回，前端只在版本变化时跳转，能省掉不少重复跳转的怪问题。

三、四种取状态通道：差别不在快慢，在成本和环境

不少方案在会议室里比延迟都比得赢，上线后才发现客户机房的反向代理三十秒就掐空闲连接、SSE 被缓冲住不下发、WebSocket 升级被中间设备拦掉，最后还是退回轮询。判断顺序建议固定：先看等待端有几个（一个标签还是多端），再看延迟是秒级可接受还是要求亚秒，最后看部署环境能不能保证长连接稳定。三步里只要有一处不成立，就不必为技术偏好硬上长连接。

• 短轮询：间隔 1.5~3 秒，前端加接口改造常见 0.5~1 人天；穿透性最好、排障最省事；代价是空请求多，等待端一多取状态接口的 QPS 会线性涨。
• 长轮询：服务端 hold 20~30 秒再返回，延迟低一档，改造常见 1~2 人天；要逐层核对网关、代理、负载均衡的空闲超时，否则容易拿到 504。
• SSE：单向推送够用，走的还是普通 HTTP，改造常见 1.5~3 人天；要确认代理没开响应缓冲。
• WebSocket：双向、延迟低，把心跳、重连、断线补偿做全，常见 3~5 人天；排障成本也高一档。

这些数字都是常见区间，只用来做量级取舍，具体还要看团队对哪种通道更熟、现有框架里有没有现成封装。

四、交付现场：卡住的往往不是间隔，是代理和多标签页

一种很典型的卡法：客户内网出口有一层代理，空闲约三十秒就断连接。前端按 WebSocket 做了等待页，办公区测试一直正常，一到会议室演示就停在「等待手机确认」。约束是代理改不了、距演示只剩一周，做法是保留 WebSocket 但补心跳，掉线几秒后自动切回短轮询，两条通道共用同一套状态机；代价是前端多了一套切换逻辑、联调多花两天，好处是后面几个客户机房都复用了这条降级路径，切换后确认到跳转仍回到 1~3 秒经验区间。

另一类更隐蔽：用户开三个标签页同时等同一张码，谁先拿到票据谁把状态推到「已使用」，另外两个页面等到过期，用户看到的就是「点了确认没反应」。常见做法是同一浏览器用 storage 事件或 BroadcastChannel 协调成单通道，只让一个页面取状态，其余订阅结果；代价是要处理页面被冻结、标签被关掉之后的重新选举。

• 确认后登录态写进 cookie，但跨域请求没带 credentials，票据换到了也登不上。
• 二维码没绑定发起端的随机值，被截图转发后别人也能确认。
• 轮询没有退避，码过期后前端还在按固定间隔打接口。

五、适用边界与验收口径

适合的：内部管理后台、企业系统、登录频次不高（每人每天几次到几十次）、等待端基本是单个浏览器，且部署环境里有改不动的代理设备。这类场景短轮询的成本和收益最匹配，先把状态机、过期、降级做扎实，比追低延迟更值。

不必上的：日登录量很小、用户本来就在同一台设备上，直接账号密码或走企业微信、钉钉免登更省事；已有稳定长连接体系（比如站内消息通道）的，复用它比自己新建一套扫码通道更划算。

验收按 2026 年项目交付习惯逐条打勾：确认到跳转，短轮询常见 1~3 秒、长连接一般在 1 秒内，明显超出就查是不是悄悄走了降级；同一张 ticket 重复换取必须失败并返回可识别错误码；过期要有明确提示且能一键换码；状态流转、通道类型、降级次数都留日志；票据一次性、发起端与确认端绑定、确认时手机上能看到当前登录的是哪个账号。

常见问题

手机点了确认，网页还是转圈，先查哪一头？

先查这张码在服务端是什么状态。已是「已确认」就查通道和跨域凭据；还是「已扫描待确认」，多半是确认请求没生效或被条件更新挡回去了。

轮询间隔从 3 秒调到 1 秒，体验会明显变好吗？

多数场景不会。间隔砍一半，空请求翻倍，等待端一多就把取状态接口的 QPS 拉起来；1.5~3 秒加上确认后即时跳转，体感差别很小。

登录二维码的有效期设多长合适？

常见 60~120 秒经验区间。太短用户来不及扫，太长旧码的风险窗口变大；关键是过期后前端能一键换新码，且服务端真的作废。

已经上了 WebSocket，还要不要留轮询？

建议留一条降级路径。代理掐连接、升级被拦、弱网断线都会让长连接失效，掉线后自动切短轮询，比让用户刷新页面重来更稳。

确认完登录态写不进去，常见是什么原因？

多落在跨域凭据没带、cookie 的 SameSite 与域名范围不匹配，或票据被前端存错位置；取值和落地日志要分开看。

如果手上这套扫码登录正卡在「确认了但页面不动」，按四态状态机逐个核对写入方，再确认通道在客户网络里真的通。能用轮询兜底的场景就先上线，把过期、换码、降级做扎实；等真出现亚秒级需求或多端同时等待，再换长连接也不迟。犀跃公司在按交付习惯做这类登录改造时，通常也是先保通、再谈延迟。