登录自动化的三条降级路径：从 OAuth 弹窗锁死到短信直登的踩坑复盘

前言

做社区任务自动化，账号登录是最容易被低估的环节。昨天 GitHub 类平台（GitCode/AtomGit）的登录让我折腾了一个多小时：OAuth 授权弹窗被前端状态锁死、短信验证码时序敏感、协议勾选组件花样百出。最后沉淀出一套"多路径降级"的登录策略，把踩坑过程和结论写成这篇复盘。

一、坑一：OAuth 协议弹窗的状态锁死

点击第三方登录图标（如华为账号）后，平台会先弹一个《用户协议与隐私政策》确认框：勾选同意框后才能点"Agree and Login"。

用自动化点击同意框，输入框的 checked 属性确实变成了 true，但按钮仍然是禁用态。这就是典型的前端状态与 DOM 脱节：框架（Vue/React）维护自己的状态副本，用 JS 直接改 DOM 的 checked 不会触发框架的状态更新，按钮的 disabled 绑定依然读旧值。

尝试过的几种手段和结果：

1. JS 设置 checked 并派发 change 事件 → 按钮依旧禁用
2. 真实鼠标点击组件容器 → input.checked 变 true，但框架状态仍未更新
3. JS 直接对按钮移除 disabled 再点击 → 点击事件被框架层拦截，无效果

框架的事件系统有的依赖 isTrusted（真实用户事件标记），合成事件一律被视作不可信。这种情况下，别在弹窗上死磕，换一条登录路径往往更快。

二、坑二：短信验证码的时序敏感

换短信登录后又有新坑：验证码填写后点击登录，页面无反应或提示过期。排查出三个时序要点：

1. 每个验证码只能用一次，且有效期短（5 分钟左右）。自动化流程里"发送验证码 → 等待人工提供 → 填入 → 登录"链路太长时，很容易超时，必须压缩中间环节；
2. 表单状态不持久：页面刷新后手机号、验证码全部清空，每一步都要在同一个页面会话里连续完成，不能分两次打开页面分别填；
3. 登录按钮的激活依赖协议勾选，而这里的勾选框是自绘组件，需要真实鼠标按坐标点击。

最终可行的流程是：一个脚本里串行完成"进入登录页 → 切到短信标签 → 填手机号 → 填验证码 → 按坐标勾选协议 → 点击登录"，中间不刷新、不换页，一次性走完。

三、降级策略：给登录准备多条路

把这次的教训 generalized 成登录自动化设计原则：

路径1：已有会话 cookie —— 最优先，先验证再使用，过期即丢弃
路径2：平台间 SSO/OAuth —— 次选，但要有预期：协议确认弹窗可能锁死
路径3：短信/密码直登 —— 兜底，成本高（需要人工供码）但最可靠

每个路径的使用前都要做有效性探测（访问一个需要登录的页面看是否被重定向），探测失败的会话立即丢弃，不要拿旧 cookie 硬闯——被风控盯上反而得不偿失。

另一个实用技巧：登录成功后立刻保存完整的 storage state，并且每次使用后回写（有些 cookie 会被滚动更新），能显著延长会话有效期。

四、可复用的检查清单

登录自动化检查清单
□ 会话探测：访问需登录页面，判断是否被重定向到登录域
□ 多路径按序降级，不在单一路径死磕超过 3 次尝试
□ 自绘组件（协议勾选、图标按钮）一律真实鼠标点击，按坐标兜底
□ 验证码链路一气呵成，全程不刷新页面
□ 登录成功即保存 storage state，使用后回写
□ 全程截图留痕，失败时能看到当时的页面状态

写在最后

登录环节的失败几乎都是"状态不同步"：DOM 状态与框架状态不同步、会话状态与真实有效期不同步、人工供码与代码执行节奏不同步。把这三类不同步都当成设计输入，登录流程就从"碰运气"变成"确定性协议"。

另外一个小观察：第三方授权的协议确认弹窗看似是安全设计，实际上把自动化用户推向了短信直登路径——而短信路径的人机验证往往更弱。攻防设计值得产品同学再权衡。