# 同一个脚本，为什么不能跑第二遍：发布流水线的幂等性设计

凌晨一点，我把博客园的发布脚本跑了两遍。

第一遍成功了。第二遍是因为不确定第一次到底有没有生效——页面上没有任何"发布成功"的反馈，我不想赌。于是脚本又灌了一遍正文，又点了一次发布。

结果你猜到了：文章正文字数变成了 **10468**，而我的源文件是 5234 字。

正好两倍。

这不是 bug，这是**幂等性缺失**。同一个操作执行两次和执行一次，结果应该一样；而我这个脚本执行两次，结果是执行一次的两倍。

---

## 一、三个平台，三种性格

同一个晚上，我在三个平台上各撞了一次"重跑"问题，但表现完全不同。

**博客园：重复即污染。** 灌正文的脚本第二次执行时，没有先清空编辑器，直接把同样的 5234 字又贴了一遍。服务端老老实实存了 10468 字。发布也成功了——一篇正文重复两遍的文章堂而皇之上了线。

**简书：重复即孤儿。** 它的建稿接口是 POST，每次调用都会新建一篇草稿。我第一次跑，建了稿 A；第二次跑，建了稿 B。现在 A 和 B 内容一样，都在草稿箱里躺着，只有一个能发出去，另一个成了没人管的孤儿。

**CSDN：重复即自愈。** 它的打标签脚本我跑过至少五次。第一次因为标签输入框没弹出来失败了，第二次带上文章 ID 重跑，好了；后来想改标签，又跑，又好了。这个脚本每次执行都先导航到指定文章、先读当前状态、再做动作——它天生就是幂等的。

同样一套自动化思路，在三个平台上呈现出三种截然不同的性格。区别不在代码量，在**有没有为"重跑"做过设计**。

---

## 二、幂等是什么，为什么这里特别重要

幂等（idempotent）的定义很朴素：

```
f(x) 执行一次的结果 == f(x) 执行 n 次的结果
```

HTTP 规范早就把这个概念用在了方法语义上：`GET`、`PUT`、`DELETE` 被定义为幂等的——重复调用不会有额外副作用；`POST` 不是——每次调用都可能创建一个新资源。

自动化脚本恰好是 HTTP 方法的放大版。把发布流水线拆开，每个动作其实都能对到某个方法上：

| 动作 | 本质 | 幂等？ |
|---|---|---|
| 读文章当前正文 | GET | ✅ 幂等 |
| 灌正文（先清空再写） | PUT | ✅ 幂等 |
| 打标签（设成固定集合） | PUT | ✅ 幂等 |
| 建新稿 | POST | ❌ 不幂等 |
| 点发布 | POST | ❌ 不幂等 |
| 上传图片 | POST | ❌ 不幂等 |

**关键洞察**：一条发布链里，只有"建稿"和"发布"是天生不幂等的，其余全都可以设计成幂等。而我踩的坑，是把一个本该幂等的动作（灌正文）写成了不幂等。

为什么自动化场景对幂等的要求比人操作高得多？因为**人天然不会重复**。你编辑一篇文章，第二次打开编辑器，看到里面已有内容，你会先删掉再写——这个"先看再删"的动作是本能，不需要思考。而脚本只会无脑执行你给它的指令，它不会"看一眼"。

所以幂等性不是锦上添花，是**把人类的本能翻译成代码**。

---

## 三、幂等的三个零件

把博客园那次事故拆开，一个幂等的"灌正文"动作需要三个零件。

### 零件一：操作前的清理

错误写法：

```javascript
// 直接把内容贴进去，不管里面原来有什么
await editor.focus();
await insert(markdown);
```

正确写法：

```javascript
// 先清空，再灌入
await editor.focus();
await selectAll();      // Ctrl+A
await press('Delete');
await verifyEmpty();    // 确认真的是空的，不是"看起来是空的"
await insert(markdown);
```

注意最后那个 `verifyEmpty`。我这次的经历是：Ctrl+A + Delete 之后读长度，读到的是 0，我才敢灌。如果读到的是别的数字，说明清理没生效，得重来，不能往下走。

### 零件二：操作后的校验

灌完之后立刻读回来，和源文件比：

```javascript
const expected = sourceFile.length;
const actual = await readEditorLength();

if (actual !== expected) {
  throw new Error('LENGTH_MISMATCH: expected ' + expected + ', got ' + actual);
}
```

这个校验是我这次唯一没做的一步。如果我做了，10468 会在发出前就被拦下，而不是等文章上线之后才发现。

**校验必须是自动的、强制的、抛异常的**。不能是"看一眼差不多就行"——脚本没有"差不多"这个判断能力，只有相等或不相等。

### 零件三：前置状态检查（可选，但能救大命）

在执行任何动作之前，先问一句"现在是什么状态"：

```javascript
const state = await readCurrentState();
if (state.isEmpty) {
  await fillAndPublish();
} else if (state.hasDraft) {
  await reuseDraft(state.draftId);   // 复用，别新建
} else {
  await createNew();                  // 万不得已才 POST
}
```

这个模式在简书上价值最大。它的建稿是不幂等的 POST，但如果前面加一层"先查有没有同标题的未发布草稿"，重跑就不再产生孤儿——第二次跑会复用第一次建的那篇。

---

## 四、正面案例：CSDN 那个"打不死"的脚本

反过来看 CSDN。它的打标签脚本我重跑过五次，每次都收敛到同一个正确状态。为什么？

```javascript
// 伪代码：cs-tag3.js 的核心结构
await navigateTo('/editor?articleId=' + articleId);   // 每次都回到同一篇文章
await waitForEditor();

const tags = await readCurrentTags();                 // 先读当前标签
const target = ['自动化', '运维'];

for (const t of target) {
  if (!tags.includes(t)) {                            // 已有就不加
    await addTag(t);
  }
}

await verify(target);                                 // 最后校验
```

三个性质让它天然幂等：

1. **锚定同一个目标**：靠 `articleId` 定位，不是"当前打开的是哪篇就操作哪篇"。
2. **先读后写**：加标签前先看已有标签，避免重复添加。
3. **终态校验**：最后检查标签集合是否等于目标集合。

这其实是**声明式**的做法：不说"做一次添加动作"，而说"确保最终状态是这个集合"。前者是过程，重复执行会累积；后者是目标，重复执行会收敛。

> 把脚本从"执行动作"改写成"达成状态"，是获得幂等性最省事的一条路。

---

## 五、还有一类幂等：故障恢复

幂等性还有个更实际的用途——**失败后重跑**。

发布链是会中途失败的。网络抖一下、验证码弹出来、平台限流、标签候选列表没加载完。这些失败发生在一个长链条的中间，前面成功的步骤不能白费。

这时候你只有两个选择：

- **从头再跑一遍**：要求整条链幂等，否则就会重复发布、重复建稿、重复上传。
- **从断点续跑**：要求每一步都有状态记录，能回答"做到哪了"。

我最终给发布链加的是第二种：每一步都把产物 ID 写进日志文件（文章 ID、note ID、slug），下一轮启动时先读日志，已经完成的步骤跳过，只做没做的。配合第一步的幂等清理，两头都有了保障。

```bash
# 断点续跑的日志长这样
51CTO=15000997
TENCENT=2760572
JIANSHU=144869424
CNBLOGS=23292556
```

下次跑同样一条链，脚本先 `source` 这个文件，发现五个平台都有 ID，就跳过发布，只做校验——确认线上文章确实存在、字数确实对。

**"可重放"比"一次成功"更重要。** 一次成功靠运气，可重放靠设计。

---

## 六、一份可以直接抄的清单

给所有要重复执行的脚本，按这个清单过一遍：

| # | 检查项 | 不做的后果 |
|---|---|---|
| 1 | 输入类操作前是否先清空 | 内容翻倍（我这次） |
| 2 | 输入类操作后是否校验长度 | 脏数据直接上线 |
| 3 | 是否锚定唯一 ID，而非"当前页面" | 操作错对象 |
| 4 | 创建类操作前是否先查重 | 孤儿资源堆积 |
| 5 | 是否"先读后写"而非无脑写 | 重复累积 |
| 6 | 终态是否校验 | 失败静默通过 |
| 7 | 是否有断点记录可续跑 | 失败后从头再来 |
| 8 | 是否显式 `process.exit(0)` | 僵尸进程挂住整条链 |

最后一条和幂等无关，但它和"重跑"是同一类问题——我的四平台链曾经被一个不退出的僵尸进程堵死十小时。**一次执行留下的痕迹，必须在执行结束时全部收干净**：打开的连接要关，起的进程要退，建的临时标签要关。

---

## 七、小结

回到那个 10468。它教会我的不是"记得先清空编辑器"这种具体技巧，而是一个判断标准：

> **每写一个要重复执行的脚本，先问自己：如果我现在立刻再跑一次，会发生什么？**

如果答案是"什么都不会发生，只是浪费几秒"——合格。
如果答案是"会再发一篇文章"——不合格，去补前置检查。
如果答案是"内容会翻倍"——不合格，去补清理和校验。
如果答案是"不知道"——那你迟早会知道，用事故的方式。

工程上把这种事叫幂等性。我更喜欢另一个说法：**对重复的容忍度**。真实世界里的操作一定会重复——手抖、网卡、不确定、想确认。一个不能容忍重复的系统，本质上是在要求操作者永远不犯错。

而那是不可能的要求。


第一遍成功了。第二遍是因为不确定第一次到底有没有生效——页面上没有任何"发布成功"的反馈，我不想赌。于是脚本又灌了一遍正文，又点了一次发布。

同一个脚本，为什么不能跑第二遍：发布流水线的幂等性设计

5234 字被灌成 10468，简书建出两篇孤儿稿，而 CSDN 那个脚本跑五遍都能自愈。同一晚的三次重跑事故，拆开讲幂等性：清空、校验、先读后写、终态收敛与断点续跑。

编程语言

同一个脚本执行两次，结果却是正文翻倍——这不是bug，是幂等性缺失。文章用三个平台的真实踩坑案例，拆解幂等设计的三个关键零件：操作前清理、操作后校验、前置状态检查，并附可直接抄的8项检查清单，教你写出“可重放”的自动化脚本，避免重复发布、孤儿资源和脏数据。

日志文件

代码解释

验证码

Markdown

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

同一个脚本，为什么不能跑第二遍：发布流水线的幂等性设计-腾讯云开发者社区-腾讯云

同一个脚本，为什么不能跑第二遍：发布流水线的幂等性设计

同一个脚本，为什么不能跑第二遍：发布流水线的幂等性设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐