短信验证码自动化的会话陷阱：为什么跨进程提交必失败

在做华为云相关页面自动化时，短信验证码登录有一个很容易踩的坑：把「发送验证码」和「提交验证码」拆成两个进程去跑，第二次打开登录页填入验证码，点登录后页面纹丝不动，既不报错也不跳转。

一开始以为是验证码错了或被风控，换验证码、换账号都一样。后来才想明白：验证码校验和浏览器会话是绑定的。短信验证码本身没错，但它属于「上一次会话」——重新打开的页面是一套全新的 Cookie 和 CSRF 状态，服务端拿着新会话去查旧会话的验证码记录，自然查不到，而前端对这种情况的处理是静默失败。

正确做法是把整个流程收敛到同一个浏览器上下文里：

一、同进程串行

发送验证码 → 轮询验证码 → 填入 → 提交，四步放在同一个页面会话里顺序执行。中间的「等验证码」用轮询外部输入（比如读一个文件、一个消息队列）来实现，进程本身不退出，会话就一直是活的。

二、等待时间要给足

用户收到短信、读出验证码、再发回来，整个链路可能要一两分钟。轮询间隔 3 秒、总时长给到 9 到 10 分钟比较稳，既不会频繁打扰，也不会把会话等到过期。

三、会话复用的两条路

1. storage_state 导出：登录成功后把 Cookie 存成 JSON，后续任务用它新建上下文，可以跨进程复用登录态。这是最常用的方式。

2. persistent profile：launch_persistent_context 用目录保留浏览器数据。但它和 storage_state 不是一回事，二者导出的会话不通用，混用会踩坑。

四、一个容易被忽略的细节

某些站点的登录接口会校验 Referer 和设备指纹，换 User-Agent 或换入口 URL 有时能绕过频率风控，有时反而触发更严的校验。遇到「提交后无反应」时，先别急着换环境，优先怀疑会话一致性；确认会话没问题后再考虑指纹层面的原因。

总结：带验证码的自动化流程，核心就一句话——验证码的生命周期和浏览器会话绑定，谁发的码谁来用，跨进程必死。把「等外部输入」做成同进程内的轮询，是这类问题最省事的解法。