用「常驻浏览器 + CDP」把扫码登录类网站自动化跑稳的三个关键点

很多人写"每天自动签到/自动领积分"的脚本，第一步就卡在登录：目标站点只给二维码，不给密码登录。脚本跑起来，二维码出来了，人还没扫，脚本已经结束——浏览器被回收，二维码成了孤儿码。反复几次就会怀疑是"码过期"，其实是进程生命周期的问题。这篇把踩过的坑归纳成三个关键点。

一、把浏览器从脚本里拆出来，做成常驻进程

默认的自动化框架往往"一次调用起一个浏览器、调用结束就关掉"。这对 CRUD 类脚本没问题，对"需要人介入扫码"的流程是致命的。正确做法是让浏览器独立存活：单独指定 --user-data-dir（保证登录态可复用）和 --remote-debugging-port，用 nohup 或 systemd 拉起来，脚本只通过 CDP 连接它、读 DOM、点按钮，不再负责它的生死。这样即使脚本异常退出，页面和会话都还在，人什么时候来扫都可以。

二、二维码是会自己轮换的，别抓一次就完事

登录页的二维码由后端签发，通常 1～2 分钟就失效，页面本身还会悄悄换新码。所以"抓一次 toDataURL 存成 PNG"这种做法必然失败——用户看到的是截图，链接早失效了。正确姿势是：循环读 canvas.toDataURL，发现内容变化就以临时文件加原子替换（open tmp 后 os.replace）写入，避免读到半个文件；展示侧用一个自刷新页面，每 3 秒带上时间戳参数重新请求图片，否则会被浏览器或 CDN 缓存住旧图。再补一条：页面提示"已失效"时，优先点它自带的"刷新"按钮，比整页 reload 稳，也不会把已经加载好的会话状态打断。

三、会话级 Cookie 不会落盘，重启就等于掉线

这是最容易翻车的一点。很多站点的核心 SessionID 是 session cookie（expires = -1），浏览器一退出就被清掉，user-data-dir 也救不回来。于是出现"明明刚才还是登录状态，改了个启动参数就全没了"。结论很朴素：一次登录、全程不重启。真要重启，就把"重新扫码"当成流程的一部分写进脚本，而不是当成意外。

顺便记两个小坑：一是某些站点的 WAF 会针对 headless 指纹直接返回 418，换成 Xvfb 下的真窗口浏览器就能过；二是跨域 iframe 里的编辑器（比如 Markdown 模式）拿不到 DOM，优先用同源的富文本 iframe，或者干脆走 API。

把这三件事做好，扫码类网站的自动化就从"看运气"变成"可预期"：浏览器活着，码一直新鲜，会话不掉，剩下的只是点按钮。