浏览器自动化登录实战：二维码、验证码与协议勾选的正确处理

登录是自动化里最脆弱的一环

用 Playwright 做网页自动化，真正拖慢节奏的通常不是业务操作，而是登录。二维码两分钟过期、短信验证码要人工中转、协议复选框看似勾了其实没勾——任何一个环节处理不好，整条流程都会卡在第一步。这篇把三类常见登录方式的做法和坑整理一遍。

一、二维码登录：链接比图片更有用

二维码登录的页面通常把二维码渲染成 canvas 或 base64 图片，直接读 DOM 拿不到可用的登录地址。更可靠的做法是监听网络请求：登录页在初始化时会向 authui/qrcode 之类的接口取二维码内容，响应里往往包含一个形如 scanlogin?qrcode_ticket=xxx 的链接。

page.on("response", async resp => {
    if ("qrcode" in resp.url):
        data = await resp.json()
        link = data.get("qrcode_content")
        if link:
            print("扫码链接：", link)
})

这里有个关键点：不要自己再请求一次二维码接口。每次请求都会生成新的 ticket，而页面轮询用的是加载时那个 client_key，两者对不上就会出现「扫码成功但页面没反应」。只抓页面自身发起的那一次请求。

拿到链接后直接把链接发给操作者，比转发二维码图片更实用——手机浏览器点开即可确认，不受图片渲染和扫码环境限制。

二、短信验证码：必须留出人工窗口

短信登录无法完全自动化，正确的心态是把它设计成「半自动」：脚本负责填手机号、点发送、等待，人负责读码。实现上可以用一个文件做中转，脚本轮询文件内容，人把验证码写进去即可。

deadline = time.time() + 500
while time.time() < deadline:
    if os.path.exists(code_file):
        code = open(code_file).read().strip()
        if code:
            break
    await page.wait_for_timeout(2000)

把等待上限设在发送后 8 分钟左右比较合适：太短容易误判超时，太长会占着浏览器空等。

三、协议勾选：视觉组件不等于原生 input

这是最容易踩的坑。很多站点用自定义复选框，真正的 input[type=checkbox] 是隐藏的，界面上显示的是带样式的 div。用 JS 把 input 设为 checked 并不能改变视觉状态，也更不会触发框架的校验逻辑。

表现为：发送验证码能成功（因为只校验 input 值），但点登录按钮没反应（因为校验读的是组件状态）。解决办法是用真实点击去操作视觉组件：

for _ in range(2):
    await page.locator(".devui-checkbox.unchecked").first.click()
    await page.wait_for_timeout(1000)

判断是否真的勾上，不要看 input.checked，而要看组件的 class 是否从 unchecked 变成 active。这一步验证过，登录成功率会高很多。

四、按钮点击没反应时，先读源码

还有一种情况是按钮明明可见、可点，却毫无响应。这时不要反复换点击方式，直接去看页面脚本：按钮的处理器可能被提交前的脚本主动移除了（防止重复提交），或者点击是在等某个前置校验。

submitBtn = document.querySelector('.publish-btn')
console.log(submitBtn.getAttribute('onclick'))  // 可能是 null
console.log(window.submitForm.toString())        // 直接读校验逻辑

把校验函数打印出来，逐条对照页面数据，往往几分钟就能定位到缺的是哪个字段，比盲目尝试高效得多。

小结

二维码抓页面自身的请求、验证码留人工窗口、协议用真实点击、按钮失灵就读源码——这四条能覆盖绝大多数登录自动化问题。自动化的价值在于把稳定流程沉淀下来，而不是把每个不稳定环节都硬编码成重试。