先描述页面停在什么位置
如果浏览器连标题和导航都没有显示，应该先确认地址是否完整、DNS是否已经解析，以及页面的样式和脚本有没有一起返回。此时反复输入账号没有帮助，因为登录流程可能尚未开始。
若页面能够打开，只有点击登录后才长时间停住，问题更接近会话、验证码、Cookie或平台响应。把“打不开”和“登录不上”分开，能够避免一开始就清理全部数据。
做一次不改变账号的对照
保持同一台设备和网络，使用隐私窗口打开相同入口。如果隐私窗口正常，旧Cookie、缓存或扩展更值得检查；如果两个窗口都在同一位置失败，再比较手机网络与当前网络。
先完成同一设备上的窗口对照，再根据结果决定是否比较网络或设备。若所有环境同时更换，即使页面恢复，也很难判断真正起作用的是哪一步。
工程设备还要留意时间与策略
项目现场的电脑可能受到组织策略、代理设置或安全软件管理。登录页脚本被限制时，普通网页仍可能显示正常，因此应记录浏览器提示和发生时间。
设备时间明显不准也会影响短时会话与验证码。先校正系统时间，再尝试一次，比连续提交验证信息更稳妥。
什么时候才处理账号
只有页面稳定显示、提交动作得到明确错误时，才进入密码、验证邮件或账号状态检查。若平台给出具体代码，应保留完整提示，不要只截取“失败”两个字。
本站提供入口与排查说明，不收集密码、验证码或恢复代码。涉及账号的操作应在当时有效的平台页面完成。
留下足够但不过量的记录
一条有效记录包含设备、系统、浏览器、网络、时间、入口地址和提示原文。它足以帮助复查，又不会暴露密码、验证码或项目文件。
问题恢复后也应补记恢复条件。工程团队共用设备较多，这条记录可以帮助其他成员直接核对相同场景。
浏览器提示要连同地址变化一起看
同一句“请求失败”可能出现在登录页、验证页或跳转后的账号页。记录提示时，把当时的域名和路径一并留下，才能知道错误属于哪个服务阶段。若地址已经离开原入口，排查对象也随之改变。
截图可以辅助说明，但不要包含密码框、验证码、个人邮箱或项目名称。能够用文字准确描述的内容，不必保存整张屏幕。
共享电脑先确认是否残留他人会话
会议室或现场共用电脑可能保留上一位使用者的会话。页面显示异常账号或权限时，应先退出并清理该站点的会话，而不是继续在原状态下操作。
若设备由组织管理，清理范围应限于当前站点。删除所有浏览器资料可能影响证书、工作平台和其他工程应用。
恢复以后再判断是否需要上报
偶发网络波动恢复后，如果没有再次出现，可以保留时间和现象作为观察。若多个成员在相近时间遇到相同阶段失败，才更像平台或区域性问题。
上报时提供现象与对照结果，不提交账号秘密。清楚说明哪些页面能打开、哪些动作失败，通常比笼统写“网站坏了”更容易处理。