浏览器自动化跑进生产的三道墙：会话、设备绑定与「看不见的界面」

用 Selenium 或 Playwright 点一个网页，本机跑得通只是起点。真正把这类自动化放进日常流程（每天定时跑、给团队用、挂在服务器上）之后，卡住你的几乎不是选择器，而是三件更底层的事：登录态到底存在哪、目标系统允许谁登录、以及界面是不是真的「看得见」。

这篇把这三道墙拆开讲，都是踩过之后才明白的。

## 一、登录态：Cookie 不总是文件

很多人默认「登录 = 拿到 cookie 文件」，于是把 `cookies.sqlite` 拷出来，用 `requests` 带着跑。这在多数站点可行，但遇到 CAS/SSO 类系统会立刻失效：

- 关键会话 cookie 的 `expiry` 是 `0`（session cookie），浏览器进程一结束就被清掉，根本不会落盘；
- SSO 的重放校验绑定 IP、User-Agent 甚至设备指纹，离线重放会拿到 `200` 但页面不跳转，属于「假成功」；
- 单点登录票据（比如 `?ticket=ST-...`）是一次性的，第二次打开必然失效。

可行做法只有一条：**让自动化附着到一个真实存活的浏览器进程上**。Firefox 用 Marionette（`geckodriver --connect-existing --marionette-port <port>`），Chrome 用 CDP（`--remote-debugging-port`）。这样登录态、扩展、指纹全在，脚本只是「替你点」。

代价是要接受一个新事实：**浏览器进程就是你的登录态**。它被杀、被系统 OOM、休眠后重建，登录就没了。所以工程上要做的不是「想办法持久化 cookie」，而是：

1. 探活看「端口是否在听」，不是 `pgrep firefox`（会误判，甚至把自家进程一起杀掉）；
2. 掉线时先看 `sessionstore-backups/recovery.jsonlz4` 能否恢复标签（部分站点能顺带把 SSO 会话带回来），恢复不了就停；
3. 停的时候把登录页摆在人面前并说清楚要做什么，而不是让脚本报一句 `NOT LOGGED IN` 就结束。

## 二、设备绑定：有密码也进不去

云厂商的沙箱、实验环境、试用账号经常带设备绑定策略。实测过的一个场景：实验台给出的 IAM 账号（租户名 + 用户名 + 密码）在自己机器的浏览器里登录，提交后直接返回：

> 检测到您的设备不安全，请更换设备登录

这不是密码错，也不是网络问题，而是策略层只允许从「实验桌面」这个受控环境登录。遇到这种提示，继续试密码、换浏览器、换网络都是浪费时间——它压根不打算让你从外部进来。

判断方法：如果「页面能打开、账号密码填得进去、提交后出现安全提示」，那就是策略拦截。此时唯一解是回到它指定的环境里操作，或者找管理员加白名单。

## 三、「看不见的界面」：VNC 不是 DOM

最容易被低估的一堵墙。很多云实验台、云桌面、远程运维面板用 VNC / SPICE 渲染进一个 `<canvas>`：

- 整页只有 1 个 `canvas`、0 个 `iframe`；
- 没有可查询的 DOM，没有可点击的元素，只有像素；
- 要操作只能「截图 → 识别 → 算坐标 → 发鼠标事件」。

也就是说，这类界面能自动化的前提是**有视觉能力**（能读图并定位控件）。如果执行环境没有图像识别能力，就会退化成「盲点坐标」——分辨率、缩放、滚动位置任一变化都会失准，不能当生产手段。

判断成本很低：进页面后查 `document.querySelectorAll('canvas').length` 与 `iframe` 数量。canvas 且无 iframe，基本可以判定「这条路对纯 DOM 自动化关闭」。

## 落地清单

- 登录态：只做「附着真实浏览器」，不做「导出 cookie 离线重放」；探活看端口。
- 一次性票据：不当长期方案，任何时候都准备好人工登录入口。
- 设备绑定：看到「设备不安全」就停止尝试，回到受控环境或申请白名单。
- 界面形态：先确认目标页是 DOM 还是 canvas；canvas 且无视觉能力，直接判定不可自动化。
- 兜底原则：**能证明自己做了什么，比「报告成功」重要**。每次操作留证据（提交后的 URL、页面关键文本、接口返回码）；失败时说清试过哪几条路、目标系统给的原文是什么。

这三道墙都不是代码问题，而是「你以为你在操作网页，其实你在操作一个受策略约束、可能根本不可见的系统」。认清这点，自动化的边界就清楚了。