用 CDP 接管常驻浏览器做每日自动化：五个真实踩过的坑

做每日签到、定时抓取这类重复操作，最省事的做法不是每次都重新登录，而是复用一份持久化的浏览器 profile。思路很简单：起一个有头浏览器，人工登录一次，之后脚本通过 CDP 接管它。但真跑起来会发现，难点几乎全在进程和状态管理上，跟页面自动化关系不大。下面五个坑都是实测出来的。

一、接管之后不要调用 browser.close()

用 chromium.connectOverCDP(port) 连上常驻浏览器后，脚本结束前如果顺手写了 await browser.close()，会把整个浏览器连同页面一起关掉——因为它关的是对端进程，不是你自己创建的那个。正确做法是直接退出进程：process.exit(0)，让连接自然断开。这个坑第一次踩到时很容易误判成"脚本把别人的窗口弄崩了"。

二、detached 不等于不会被回收

要让浏览器在脚本退出后继续活着，常规写法是 spawn(execPath, args, { detached: true, stdio: 'ignore' }) 加 child.unref()。这在普通终端里成立，但如果脚本跑在一个把命令放进进程组、命令结束就清理整组的宿主里（IDE 终端、CI runner、各类 agent 沙箱），子进程照样会被带走。

症状很有欺骗性：拉起方打印"已启动"（因为它轮询到调试端口通了才返回），几秒后端口就变成"目标计算机积极拒绝"。因为 stdio 设成了 ignore，崩溃信息也被吞了，什么都看不到。

判据只有一个：curl -s http://127.0.0.1:PORT/json/version 返回 JSON 才算真的活着。启动日志不算证据。

三、端口就是身份

每个账号一个 profile、一个调试端口，这套映射关系必须固定。曾经手动把端口从 9222 改成 9300 起浏览器，结果其它脚本按配置连 9222，怎么都连不上，日志里只有一句"连不上常驻浏览器"。后来统一成"只按注册表里的端口连"，问题消失。改端口要改配置，不要在命令行临时改。

四、同一个 profile 不能被两个进程同时打开

launchPersistentContext 抢同一个 user-data-dir 时，Chromium 会报 profile 被占用，或者干脆起不来。所以同一账号的脚本必须串行，跨账号才可以并行。做批量任务时如果不注意这点，会得到一堆随机的启动失败。

五、登录态判定别用 class 或头像猜

页面里常有空的头像占位、隐藏的登录按钮之类元素，用 [class*=avatar] 判断登录状态会误判。可靠的判据是文案：未登录时页面会显示"登录/注册查看您的积分"这类提示，登录后消失。SPA 首屏渲染慢，还要轮询到出现明确信号为止，固定 sleep 几秒是不够的。

小结

这套东西的复杂度不在"点击按钮"，而在"让浏览器以可预期的方式活着并且只属于一个账号"。把进程复用、端口固定、profile 独占、登录态判据这四件事定死，剩下的选择器问题反而好排查。