# 无人值守发布最怕静默掉登录：持久化档案的失效检测、扫码恢复与三域隔离

我的 WorkBuddy 里跑着一条每日发文自动化，工作日上午 10 点自动往腾讯云开发者社区发一篇原创教程。流水线本身我已经写过搭法（Playwright 持久上下文 + 自动传图 + 发布验证），但这条流水线真正的命门不是排版、不是图片、也不是审核——是**登录态**。脚本再稳，浏览器一旦静默掉登录，后面所有步骤全部白跑。这篇就把我踩过的失效事故、最后沉淀下来的检测与恢复方案完整讲一遍。

## 一、输入材料：一次持续三天的失效事故

9 月 13 日之前，流水线一切正常。9 月 14 日早上，自动化第一次跑挂了，症状非常隐蔽：

| 日期 | 现象 | 初步判断 |
|---|---|---|
| 9/14 | 打开写作页被重定向到 `/login`（URL 带 `s_url` 回跳参数），编辑器未加载，填标题超时 FATAL | 登录态过期 |
| 9/15 | 打开创作者中心被重定向到社区首页，截图确认是未登录态 | 与 9/14 同根因，连续第 2 天 |
| 9/16 | 症状完全一致，连续第 3 天 | 确认登录态彻底失效 |

这三天暴露了一个无人大海的典型困境：**脚本挂在"填标题超时"这种下游症状上，根因却在最上游的登录态**。如果只在下游重试，永远修不好。

正面参照是恢复之后的数据：9/17 扫码恢复登录后，到 10 月 6 日整整 20 天、20 次发布，登录检测一次都没有误报过——说明问题不在浏览器指纹或风控，纯粹是 cookie 过期了没人管。

## 二、WorkBuddy 配置：三层登录态防护

### 2.1 持久化档案（第一层：让登录态能"存下来"）

Playwright 默认每次启动都是全新浏览器，登录一次丢一次。方案核心是把用户数据目录固定下来：

```js
const { chromium } = require('playwright-core');
const PROFILE = 'C:/Users/Administrator/.agent-browser/profiles/pw1';

const ctx = await chromium.launchPersistentContext(PROFILE, {
  executablePath: CHROME,          // 固定版本的 Chrome
  headless: false,                 // 扫码时必须有头
  viewport: { width: 1380, height: 900 },
});
```

cookie、localStorage、session 全部落盘在 pw1 目录，下次启动自动带上。**关键原则：登录态属于档案，不属于"人"**——你在 Edge 或另一个 Chrome 里登录过，对 pw1 毫无帮助。

### 2.2 发布前置检测（第二层：把失效拦在第一步）

daily_publish.js 打开编辑器后先做双重检测，任何一条命中即判定未登录，以**专用退出码 2** 终止：

```js
await page.goto(EDIT_URL, { waitUntil: 'domcontentloaded' });
await page.waitForTimeout(10000);

const needLogin = page.url().includes('/login') ||
  await page.evaluate(() => !!document.querySelector('.cdc-header__account-btn'));
if (needLogin) {
  log('FATAL: 登录状态失效，需人工在 Chrome 窗口重新扫码');
  await page.screenshot({ path: OUT + '/daily_need_login.png' });
  await ctx.close();
  process.exit(2);   // 专用退出码：登录失效 ≠ 其他失败
}
```

两个检测点各有分工：URL 重定向抓"已被踢出"，`.cdc-header__account-btn` 抓"页面没跳转但导航栏显示未登录"的边缘情况。退出码专门区分开，是为了让上层的自动化任务读到 2 时直接停手，**不浪费重试次数**——登录失效重试一百次也不会自愈。

### 2.3 扫码恢复脚本（第三层：把人工动作缩到最短）

恢复不要手工摸流程，专门写了 wait_login.js：

```js
const LOGIN_URL = 'https://cloud.tencent.com/login?s_url=' +
  encodeURIComponent('https://cloud.tencent.com/developer/article/write');

// 打开登录页 → 轮询 URL 是否离开 /login → 成功则登录态自动写回 pw1
while (Date.now() < deadline) {          // deadline = 10 分钟
  await page.waitForTimeout(3000);
  const url = page.url();
  if (!url.includes('/login')) { ok = true; break; }
}
```

人只需要做一件事：在弹出的 Chrome 窗口里勾协议、微信扫码。轮询看到 URL 离开 `/login` 即判定成功，截图留档，关窗。整个恢复动作不到一分钟。

## 三、操作步骤：失效诊断与恢复 SOP

结合三天事故的排查过程，整理成四步：

1. **看退出码分流**：自动化任务读到退出码 2 → 登录失效路径；其他非零退出码才走常规重试。9/14 第一天挂的时候还没有这个区分，脚本按普通失败处理，白白烧了一次机会。
2. **看 URL 判失效层级**：打开写作页若被重定向到 `/login?s_url=...`，说明 cookie 已彻底过期；若 URL 正常但操作超时，先截图看导航栏是不是"未登录"状态，再下结论。
3. **跑 wait_login.js 扫码**：弹出 Chrome → 微信扫码 → 脚本轮询确认 → 登录态写回 pw1。9/17 就是靠这一步恢复的。
4. **跑一次 list_articles.js 验证**：能列出已发文章列表 = 登录态真正可用，再放行当日发文。9/17 恢复当天就是这么验证的。

过程中踩了三个坑，每个都值得单独说：

- **坑 1：跨域扫码互不相通。** pw1 里同时存过腾讯问卷（wj.qq.com）和腾讯云社区（cloud.tencent.com）的微信登录态，但它们是**各自独立的域**——给问卷扫码不会让社区恢复登录，反之亦然。工作区还试过另一个域名（workbuddy.cn）的探针脚本，即便社区已登录，它依然返回未登录。**每个域要单独扫码，不要想当然地"应该通"**。
- **坑 2：换浏览器登录无效。** 用户在 Edge 或系统 Chrome 里登录得再彻底，pw1 档案里的 cookie 依然是过期的。恢复动作必须发生在**持久档案对应的那个 Chrome 窗口**里。
- **坑 3：headless 下没法扫码。** 恢复脚本必须 `headless: false`。曾经想图省事用无头模式跑恢复，结果二维码扫不了，白折腾一轮。日常发布倒是可以无头，但我的档案从第一天起就有头跑，索性统一。

## 四、产出物：退出码语义表与 20 天稳定运行记录

方案沉淀下来两份可复用资产：

**退出码语义表**（上层自动化按此分流，不盲目重试）：

| 退出码 | 含义 | 上层动作 |
|---|---|---|
| 0 | 发布成功 | 照常记录，验证 daily_final.png |
| 2 | 登录态失效 | 停止重试，提醒用户扫码，当日发文顺延 |
| 其他非零 | 脚本/页面异常 | 最多重试 2 次，截图定位 |

**稳定性记录**：9/17 恢复至今 20 天，20 次发布全部成功，登录检测零误报、零漏报。9/14-9/16 那三天是唯一的失效窗口，而这三天恰好是方案补齐之前——检测、恢复、隔离三层都到位之后，再没有出现过一次登录问题。

一句话总结：无人值守自动化的可靠性，上限不在主流程写得多漂亮，而在**你能不能第一时间知道"该人来修了"**——专用退出码负责喊人，持久档案负责让人少扫码，域隔离负责让人别扫错地方。
![daily_content.png](https://developer.qcloudimg.com/http-save/yehe-12639135/0c6f081bda99a4add45580aa6aa2878d.png)![daily_img_inserted.png](https://developer.qcloudimg.com/http-save/yehe-12639135/4f14648727207e881938b1acc82fd047.png)![daily_final.png](https://developer.qcloudimg.com/http-save/yehe-12639135/42af703847f1ae8a409f4558f25a6679.png)

我的 WorkBuddy 里跑着一条每日发文自动化，工作日上午 10 点自动往腾讯云开发者社区发一篇原创教程。流水线本身我已经写过搭法（Playwright 持久上下文 + 自动传图 + 发布验证），但这条流水线真正的命门不是排版、不是图片、也不是审核——是登录态。脚本再稳，浏览器一旦静默掉登录，后面所有步骤全部白跑。这篇就把我踩过的失效事故、最后沉淀下来的检测与恢复方案完整讲一遍。

#WorkBuddy# #AI办公# 无人值守发布最怕静默掉登录：持久化档案的失效检测、扫码恢复与三域隔离

运维

开发工具

后端

无人值守发布最怕静默掉登录：本文拆解三天连续失效事故，提供持久化档案、双重发布前检测、专用退出码及扫码恢复SOP。通过三域隔离与10分钟轮询恢复，实现20天零误报稳定运行。覆盖跨域扫码坑位、headless限制，适合Playwright自动化流程防掉登录场景。

2026上云采购 | AI焕新·智启新局

workbuddy

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

#WorkBuddy# #AI办公# 无人值守发布最怕静默掉登录：持久化档案的失效检测、扫码恢复与三域隔离-腾讯云开发者社区-腾讯云

#WorkBuddy# #AI办公# 无人值守发布最怕静默掉登录：持久化档案的失效检测、扫码恢复与三域隔离

#WorkBuddy# #AI办公# 无人值守发布最怕静默掉登录：持久化档案的失效检测、扫码恢复与三域隔离

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐