更新时间：2026年10月15日

扫码登录要先把电脑与手机当作两块相互关联的界面：电脑展示待扫描二维码，手机说明要登录的设备和账号，用户确认后，电脑再依据服务端结果进入目标页面。至少画出待扫描、待确认、拒绝、过期和结果未知几种状态；刷新二维码或切换登录方式时，还要明确旧流程是否已经结束。

以员工打开工单平台为例，他要回到刚才点击的工单，而不是完成登录后重新找一次入口。用Pixso的交互原型把桌面登录页、手机确认页和工单详情连接起来，可以提前检查两端提示是否一致，以及中途取消后能否继续处理工作。

电脑和手机分别需要告诉用户什么

桌面页应说明用什么应用扫码，并提供其他可用登录方式。二维码本身不承担说明文字的工作：用户可能拿系统相机扫描，也可能尚未安装指定应用。若只能使用企业应用，就在码旁写清要求；若扫码可打开网页，则设计好从浏览器继续的路径。二维码应留出清晰边界，不能被品牌图形或装饰遮住。

手机页的核心是确认这次登录，而不是再展示一张二维码。标题可写“登录工单平台”，下方呈现当前账号及经过系统确认的设备信息。设备、浏览器、时间等只显示真正获得的字段，不凭空补一个精确地理位置。两个按钮分别表达“确认登录”和“取消”，不要让含义模糊的“继续”成为唯一决定。

两端可以使用相同的产品名和设备描述，帮助用户对上当前操作。账号头像加载失败时仍需保留可识别的文字；手机切换到另一个账号后，确认页也要更新，不能让旧头像和新身份同时出现。

用一张双端状态表约束提示

微软设备授权文档也区分授权等待、用户拒绝与过期，并分别规定客户端后续动作。扫码页可据此区分继续等待、结束本次请求和重新发起；二维码的实际有效时间应从本次会话结果读取。

最容易漏掉的是两端不同步。员工已经扫描二维码A，尚未确认；电脑因等待太久生成二维码B。此时手机A的确认按钮若仍看似有效，用户点完就会困惑：为什么电脑还在等扫描？

设计交付要给每次登录尝试一个独立身份，并标明刷新后的旧请求处理规则。界面不必向用户展示内部会话编号，但状态图可以用A、B区分。若刷新会撤销A，手机收到失效结果后应明确说明“二维码已更新，请重新扫描”，不再允许它显示登录成功。仅替换二维码图片，而不处理旧请求，会留下完整的交互缺口。

过期也需要停止原来的等待表现。桌面不要在失效二维码后面继续无限转圈；手机不要把确认失败解释成“密码错误”。刷新操作应生成新的尝试，点击后暂时抑制重复操作，并区分“正在生成新码”与“新码生成失败”。

手机确认成功与电脑收到结果之间可能有短暂间隔。电脑网络异常时，可以显示“暂时无法获取登录结果”，保留查询当前结果的动作。不能仅因为页面等待超时就断言登录失败，更不能立即清掉原目标工单，让员工重新开始。

结果恢复应先询问当前这次会话是否已经完成，再决定进入页面、继续等待或重新发起。用户主动刷新二维码和系统重查结果是两件事，按钮文案应区别，例如“重新检查”与“换一个二维码”。原型需要各演示一次，避免研发将它们实现为同一个动作。

如果账号已确认但无权访问原工单，登录成功后进入的应是权限说明页，而不是让用户再次扫码。这里可以沿用权限不足与申请访问的页面流程，让身份验证和业务访问各自有明确结果。

在Pixso文件中，把电脑画板放在上排、手机画板放在下排，按等待扫描、待确认、二维码失效和登录完成排列。用相同的状态名称对应两端，另放一条“电脑刷新A为B”的分支，手机旧确认页连接到失效说明。这样评审者可以看到是哪一次请求在继续，而不只是看到几张孤立的登录页。

第一次演示走正常路径：打开工单、扫码、确认、回到工单。第二次故意在手机确认前刷新电脑二维码，检查旧请求提示。第三次在手机确认后让电脑进入网络异常画板，观察“重新检查”是否会恢复原结果。页面中的账号和工单内容使用合成数据，画板中的二维码只表现布局，不连接真实登录会话。

最后把切换密码登录也接入同一流程：用户切换后不应突然被旧扫码回调带走；返回扫码页时，应清楚是恢复仍有效的尝试还是生成新码。把切换条件、手机旧确认页的文字和桌面最终落点标在对应画板旁，再从密码登录切回扫码，检查这次回到的是有效请求还是新二维码。