企业官网建设流程全解析

做多平台自动化时，最绕不开的需求就是"多账号"：同一台机器上要同时登录多家平台的多个账号，彼此不能串号，还要能稳定复用登录态、能远程接管浏览器干活。

很多方案选择给每个账号单独开一个虚拟机或容器，隔离是彻底了，成本和维护复杂度也上去了。本文分享一条更轻的路径：基于 Chrome 的 User Data Directory（用户数据目录）做进程级隔离，再用 CDP（Chrome DevTools Protocol）统一管理会话。整套方案在单机上即可运行，账号之间互不干扰。

## 一、为什么"共用一个浏览器"会串号

浏览器把登录态存在 Cookie 里，而 Cookie 是按域名隔离、按 Profile 存储的。问题出在"Profile"这一层：

默认情况下，程序启动的浏览器进程共用一个默认 Profile。账号 A 登录了平台 X，账号 B 再登录同一个平台 X，后登录的会把先登录的顶掉——因为它们的 Cookie 写在同一个 Profile 里，同域名的 Cookie 是同一份。

所以多账号隔离的第一原则是：**每个账号一个独立的 User Data Directory**，让各自的 Cookie、LocalStorage、IndexedDB 互不可见。

## 二、进程级隔离：一个账号一个数据目录

启动 Chrome 时通过 `--user-data-dir` 指定独立目录：

```js
const { spawn } = require('child_process');

function launchChrome({ port, userDataDir, headless = true }) {
const args = [
'--headless=new',
'--no-sandbox',
'--disable-gpu',
`--remote-debugging-port=${port}`,
'--remote-allow-origins=*',
`--user-data-dir=${userDataDir}`,
];
const proc = spawn(CHROME_PATH, args, { detached: false });
return proc;
}
```

几个要点：

- **`--remote-debugging-port` 每个账号一个独立端口**，方便用 CDP 精确连接到对应账号的实例。
- **`--remote-allow-origins=*` 必须带**。新版 Chrome 对 CDP 的 WebSocket 连接有 Origin 校验，不带这个参数，playwright/puppeteer 的 `connectOverCDP` 会连接被拒。
- **目录里加一个 `.owner` 标识文件**，记录这个实例属于哪个账号、哪个平台。机器上实例多了之后，靠端口号记不住，靠文件标识最可靠。

## 三、连接前先探活，避免连到"僵尸实例"

实例是常驻的，进程可能因为各种原因挂掉：内存不足被系统回收、授权操作时被别的角色误关、机器重启后没自动拉起。

直接 `connectOverCDP` 会抛 `ECONNREFUSED` 或 404。工程上要做的，是连接前先探活、失败后能自愈：

```js
async function connectToBrowser(port, ensureLaunch) {
for (let attempt = 0; attempt < 5; attempt++) {
try {
const browser = await chromium.connectOverCDP(`http://127.0.0.1:${port}`);
// 用 /json/version 验证目标确实是我们想要的浏览器
await browser.version();
return browser;
} catch (e) {
if (attempt === 0 || /404|ECONNREFUSED/.test(e.message)) {
await ensureLaunch(); // 实例没了就重新拉起
}
await sleep(1000 * (attempt + 1));
}
}
throw new Error(`port ${port} connect failed after retries`);
}
```

注意一个容易踩的坑：**connectOverCDP 成功不代表实例健康**。端口上有服务响应，未必是你要的那个浏览器——可能是别的进程恰好占了端口。所以探活要校验 `/json/version`，最好再比对实例的启动特征（如 user-data-dir 路径）。

## 四、登录态复用与"会话级失效"

隔离做好后，登录态复用是下一个关键点。

同一账号的 Cookie 存在它的数据目录里，只要目录不删、浏览器版本不变，登录态就能跨进程、跨命令复用——下次干活不用重新扫码登录。

但有两类失效要特别处理：

**第一类：会话级 Cookie。** 部分平台的登录态是"会话级"的，关掉浏览器进程就失效。表现为：手动授权时明明登录成功了，进程一关，下次再来又是未登录。对这类平台，要么让浏览器进程常驻不关，要么授权后立刻把 Cookie 导出存档，下次用 Cookie 注入的方式恢复。

**第二类：系统级加密导致的全量失效。** 在 Windows 上，Chrome 的 Cookie 用 DPAPI 按"用户 + 系统"加密存储。整机重装或跨机迁移后，即使把数据目录整个拷过去，Cookie 也解不开——所有账号同时"掉线"。这是迁移场景里最隐蔽的坑，只能靠迁移后全部重新授权解决，没有捷径。

## 五、多角色共用实例时的"心跳"约定

在真实的发布系统里，一个账号的浏览器实例往往不是单一角色在用：发布任务要用、登录态巡检要用、人工授权也要用。多角色并发操作同一个实例，会产生竞态——最常见的是 A 角色在发布中，B 角色误以为实例异常把它重启了。

工程约定比技术手段更有效。实践中用的是"心跳文件"：

- 发布任务开始时，在实例目录写一个 `.publishing` 文件，带时间戳和 TTL（如 15 分钟，覆盖两篇文章之间的休息时间）；
- 巡检、探活等其他角色看到该文件且未过期，就跳过这个实例，不碰它；
- 任务结束或 TTL 过期后删除/忽略心跳，其他角色恢复接管。

这套"谁在用谁声明"的约定，比任何锁都简单，也基本够用。

## 六、关闭实例的正确姿势

最后一个坑：怎么"关浏览器"。

如果用的是 playwright/puppeteer 的 `connectOverCDP` 连上的实例，调用 `browser.close()` 大概率只是断开 CDP 连接，**Chrome 进程本身还活着**（这是 CDP 远程连接的特性：close 只关协议连接，不杀远端浏览器）。

要真正关掉实例，两条路：

```js
// 方式一：走 CDP 的 Browser.close（会真正关掉 Chrome）
const cdp = await browser.newBrowserCDPSession();
await cdp.send('Browser.close');

// 方式二：直接杀进程（慎用，会无差别结束该端口的进程）
// process.kill(pid) / taskkill /pid /f
```

方式二容易误伤，非必要不用；优先用 CDP 的 `Browser.close`，干净且只关自己管理的那个实例。

## 七、总结

多账号浏览器隔离的完整方案可以浓缩成几条：

1. 一个账号一个独立 User Data Directory + 独立 CDP 端口，从根上杜绝串号；
2. 连接前探活、失败按退避重试、必要时自动拉起实例；
3. 会话级登录态要导出归档，迁移后 DPAPI 加密会导致全量失效，只能重新授权；
4. 多角色共用实例用"心跳文件"声明占用，避免互相误杀；
5. 关实例用 CDP `Browser.close`，不要依赖 `browser.close()` 断开连接。

这套方案不需要虚拟机，不需要容器，一台普通机器就能稳定跑几十个账号的隔离实例。自动化跑得越久越会发现：多账号的难点不在"登录"，在"隔离"与"会话的生命周期管理"。

（本文由一支长期做企业内容工程与多平台自动发布的技术团队整理，欢迎同行交流指正。）