用 CDP 直连 Chrome 做无人值守运维：五个真踩过的坑

这两年我把一批"每天要点一下"的网页任务改成了无人值守脚本，走的路子不是 Selenium，也不是 Playwright，而是直接用 Chrome 的远程调试端口（CDP）说话。原因很实际：目标页面是重度 SPA，登录态是靠 cookie 和设备指纹维持的，一旦换浏览器实例就得重新认证；而 Selenium/Playwright 默认会自己拉起一个干净的实例，把最值钱的登录态丢掉。CDP 直连已有的那个 Chrome，会话是原封不动的。

这条路省钱，但坑不少，下面五个都是我自己踩出来的。

一、以为"连上了"就等于"连对了"

Chrome 的 /json 接口会返回所有 target，包括大量 type=service_worker、iframe、扩展页。第一次写的时候我直接取了列表第一个 page，结果某天 Chrome 崩溃恢复后，排在最前面的是 chrome://password-manager，所有导航和点击都打在密码管理器上，脚本还一本正经地报"成功"。

修法很简单，但必须写：给 target 打分，业务域名优先、普通 http(s) 次之、chrome:// 排最后。这个排序后来救了我好几次。

二、标签页会自己跑掉

SPA 里点一个"去完成"，常见行为是新开标签页。此时老的 CDP session 还连着原来那个 tab，你在它上面找元素永远找不到。正确做法是操作完主动列一遍 target，比对操作前后的 URL 集合，把新增的那个 attach 过来；任务结束后再 window.close() 收掉，否则开几十个标签页，内存和渲染进程都会被拖垮。

还有个更阴的：有些按钮会用 window.open 打开新窗口，而 Chrome 的弹窗拦截在某些启动参数下会把它降级成同标签跳转。同一个点击在不同机器上行为不同，所以判断"跳没跳"要靠 URL 变化，不能靠有没有新 target。

三、JS .click() 和真实鼠标点击不是一回事

这是最贵的一课。页面上一个"信任此浏览器"的确认框，用 element.click() 打上去，界面关了，日志写着"已点信任"，但服务端根本没收到请求——因为事件绑定在包裹层的 mousedown/mouseup 上，合成 click 不触发它。结果整条登录链路卡在最后一步，表现为"验证码正确但登录失败"，排查了两小时。

结论：凡是会引起状态变更的按钮，一律用 CDP 的 Input.dispatchMouseEvent 发真实鼠标事件（先 mouseMoved，再 mousePressed/mouseReleased，坐标取 getBoundingClientRect 的中心）。纯导航类的 a 标签可以用 .click() 省事。

四、隐藏镜像框：填充了，但等于没填

很多站的密码框是双份的：一个可见的 input，一个隐藏的镜像（用来对接浏览器的自动填充）。Chrome 的 autofill 会把值写进隐藏那个，可见框仍是空的，前端校验直接判"密码为空"。

解法是把隐藏框的 value 取出来，用 HTMLInputElement.prototype 上原生的 value setter 写进可见框，然后依次派发 input、change、keyup 三个事件，让框架的脏检查认账。少派发一个，某些框架就不更新状态。

五、别把"页面看起来对"当成成功

早期我用 document.body.innerText 里有没有某个关键词来判断成败，栽过假阳性：那个关键词同时出现在导航栏和帮助链接里，未登录页也命中，于是脚本认为已登录，后面所有操作全错。

现在的判断标准只有两条：一是 URL 里有没有一次性票据（ticket=），二是页面上有没有只有登录后才渲染的数据块。两条都满足才算成功，缺一条就重试。宁可多等一轮，也不要带着错的判断往下跑。

最后说一句工程上的取舍：CDP 直连的代价是必须维护一个常驻 Chrome，机器重启、Chrome 升级、profile 损坏都要有人兜底。所以我又加了一层守护——每两分钟检查端口和进程，掉线就拉起，登录态失效就出二维码等人扫。整套东西不优雅，但两年下来没漏过一天任务，这就够了。