浏览器自动化或多账号环境里，登录页异常很常见。
常见表现包括：
这类问题不建议一上来就改脚本，也不建议马上换代理。更稳的做法，是先把现场记录下来。
如果没有现场记录，排查会变成猜：可能是账号问题，可能是代理问题，可能是 Cookie 问题，也可能是页面状态变了。
先记录登录页现场
最少要记录这些字段：
这一步的目标不是马上修复，而是保留证据。
很多登录问题会在刷新、重跑、人工接手后消失。如果没有第一现场，后面只能靠记忆复盘。
URL 和状态码能先分层
登录页异常可以先从 URL 和状态码分层。
如果状态码是 200，但页面内容不是目标后台，说明请求成功了，但业务状态不对。常见原因是登录态失效、账号需要验证、权限不足或跳到了地区/语言不同的页面。
如果状态码是 302 或多次重定向，要记录每一次跳转。它可能是正常登录流程，也可能是会话失效、地区切换或安全验证入口。
如果状态码是 403、429、5xx，就不要只盯 DOM 元素。此时更应该查代理、请求频率、服务端响应、账号状态或目标平台临时问题。
如果脚本只记录“找不到按钮”，但没有记录 URL 和状态码，就很容易把服务端、网络、权限问题误判成前端选择器问题。
截图要截关键状态，不只是最后失败页
截图也要分层。
建议至少保留三类截图：
如果是自动化任务，还要记录失败步骤对应的截图。
例如：
step_01_open_login.png
step_02_after_submit.png
step_03_verify_required.png
这样排查时能看出问题发生在输入前、提交后、验证阶段，还是跳转后的后台页面。
只保留一张最后截图，经常不够。
Profile 上下文必须一起看
登录页异常和 Profile 关系很大。
需要检查：
如果账号在多个 Profile 之间来回切换，或者 Profile 的代理和地区经常变化，登录页异常就很难只从代码层解释。
代理、语言和时区只看当前值不够
很多排查只看当前代理是否可用，这还不够。
更应该看变更过程：
登录页异常经常不是“代理不可用”，而是上下文变化太多，排查时不知道哪一次变更产生影响。
自动化任务要有停止条件
如果登录页进入异常状态，脚本不应该继续猜。
建议设置停止条件：
触发这些条件时，任务应该停止并记录现场，而不是继续点击。
一个可复盘的失败，比一个继续乱跑的任务更有价值。
一个推荐排查顺序
可以按这个顺序处理：
这样排查，能把“页面状态问题”“账号环境问题”“代理问题”“脚本问题”分开。
团队最好把现场记录沉到工作流里
如果只是个人调试，用截图文件夹和简单日志也能解决一部分问题。
但团队场景里，最好把 Profile、代理、登录态、任务步骤、截图和错误信息放到同一套记录里。否则每次排查都要在浏览器、代理后台、聊天记录、脚本日志之间来回找。
如果团队已经需要多人协作、任务巡检和异常复盘，可以参考这种把登录页现场、Profile 上下文和任务日志放进同一套浏览器工作流的方式。
重点不是跳过验证，也不是复用 Cookie，而是让每次异常都有可查的现场：哪个账号、哪个 Profile、哪条代理、哪个 URL、哪一步任务出了问题。
登录页异常不可怕，真正麻烦的是没有现场。先记录，再判断，排查效率会高很多。
