无人值守浏览器任务：登录态、二次验证与风控的工程处理

背景

把「每天定时打开某平台执行若干操作」做成无人值守任务，看起来只是把手工步骤脚本化。真正上线才发现，难点几乎都不在业务操作，而在登录这一关：本地调试一切正常，定时任务一跑就静默空跑，结果里只留下一句「未登录」。

本文整理一次真实排查中踩到的三个坑，以及对应的工程处理方式。为便于复用，下面不绑定任何具体平台。

一、登录态不会跨会话继承

本地浏览器明明是登录状态，但定时任务在独立沙箱中启动，拿到的是一个全新的浏览器上下文：空白页、cookie 为空。之前手工登录写入的设备凭证、会话 token 都带不过去，连浏览器调试端口都可能需要重新拉起。

结论：不能把「已登录」当作默认前提。任务第一步必须显式探测登录态，并且为「未登录」分支准备可执行的恢复动作，而不是记录一句就退出——那样后续所有步骤都会空跑。

探测方式可以很轻：打开目标页后检查关键 DOM（用户头像或昵称是否出现、登录/注册按钮是否消失），比只判断 URL 是否跳转可靠得多。

二、二次验证是硬门槛，别假装能自动化掉

即使配置了账号密码，平台仍可能弹出「需要验证您的身份」并要求短信验证码，且验证码通常只有几分钟有效期。这意味着「账号密码 + 完全无人值守」在开启二次验证的账号上并不成立。

可行的做法有三种，实践中一般组合使用：

1. 信任设备：登录后选择「信任此浏览器」，平台写入长期设备凭证，同一浏览器上下文后续可免验证码。注意它绑定的是浏览器 profile 而不是账号，profile 重建即失效。
2. 凭证持久化：把 cookie 或 storageState 导出成文件，任务启动时先注入；同时要处理 token 过期与文件跨沙箱的可见性。
3. 人工降级通道：识别到验证码界面时暂停并推送请求，拿到码后继续；超时则记录失败并跳过，绝不反复重试。

把「需要人工介入」显式列为一个分支，比让脚本在验证码页面反复提交要健康得多。

三、风控往往比验证码更早出现

短时间内反复登录、退出，会触发平台风控，返回「检测到设备不安全，请更换设备登录」之类的错误页。它和验证码不同：没有输入框，只有一个错误码和刷新按钮，很容易被脚本误判成网络抖动而不断重试，反而加重风控。

工程上建议把这类响应单独归类：命中风控特征（错误码、特定文案）时立即停止重试并做指数退避；尽量复用已有会话，降低登录频率；把「环境异常」和「凭据错误」分开统计，否则监控会一直误报。

四、让任务可观测

最后补了三件事：每个子步骤独立捕获异常，单项失败不影响后续步骤；执行结束输出结构化摘要（成功、跳过、失败原因）；关键页面截图落盘。这样第二天看结果就能定位是哪一环断了，而不是只看到「任务失败」四个字。

小结

无人值守浏览器任务的可靠性，主要取决于三件事：登录态是否显式管理、二次验证是否有人工降级通道、风控是否被正确识别并退避。业务操作反而只是顺序调用。把登录当成一等公民来设计，任务才不会在凌晨静默空跑。