版本戳：别让旧数据悄悄覆盖新数据

你打开商品页面时，看到某款键盘还剩 8 件，价格是 399 元。你想了一会儿，填好地址，再点击“确认购买”。偏偏就在这几分钟里，运营把价格调成了 429 元，另一位用户也买走了最后几件库存。此时真正棘手的问题并不是“数据库能不能完成一次写入”，而是：你准备提交的决定，仍然建立在最新数据上吗？

后台管理也会遇到同样的麻烦。两位同事同时打开一份自动化流程配置，一个修改重试次数，另一个修改回调地址。如果两个人保存时都直接把整份文档覆盖回去，后保存的人可能完全不知道，自己顺手抹掉了先保存的修改。

版本戳就是为这种时间差准备的。它会随着数据版本变化而变化，让系统在写入前确认：“你现在修改的，还是你刚才读到的那一版吗？”确认一致才写入，不一致就拒绝、重读或进入冲突处理。这个思路通常叫做乐观并发控制：我们允许大家先读、先编辑，不长期占着锁，只在落笔的最后一刻核对版本。

业务过程很长，数据库事务必须很短

我们先把两种容易混在一起的“事务”拆开。

业务事务是用户心中的完整过程。浏览商品、比较价格、填写地址、提交订单，可能持续几分钟；一份流程配置从打开、讨论、修改到保存，甚至可能持续半小时。

系统事务是数据库真正保证原子性的短操作。它通常只覆盖最后几条读写，例如扣减库存、创建订单、记录支付请求。数据库可以保证这些操作要么一起成功，要么一起失败，但它不会自动知道用户十分钟前看见了什么。

如果我们从用户打开页面那一刻就启动数据库事务，并一直持有到用户点击保存，锁会跟着用户一起“发呆”。有人离开工位去倒杯水，其他请求就可能长时间等待；连接、内存和锁资源也会被白白占住。系统并发一高，这种做法很快就撑不住。

所以实际系统会把事务压缩到最后几毫秒或几秒。这样性能问题解决了，却留下一个时间窗口：页面里的数据可能已经过期。版本戳正好跨过这个窗口，把“当时读到的版本”带回提交现场。

丢失更新是怎么发生的

假设流程文档当前是：

{
  "id": "flow-1024",
  "retryLimit": 3,
  "callbackUrl": "/hooks/order",
  "version": 7
}

小林和小周都读到了版本 7。小林把 retryLimit 改成 5 并先保存，数据库里的版本变成 8。小周的页面仍停留在版本 7，他只想改回调地址，但客户端提交的是整份旧文档。如果服务端不检查版本，小周的保存会把 retryLimit 又覆盖成 3，小林的修改就像从没发生过一样。

注意，这里未必出现报错。两次写入都可能返回“成功”，最后的数据却是错的。静默发生，正是丢失更新最危险的地方。

下面这个小实验把两种写法放在一起。先让甲、乙都读取同一版本，再切换写入模式，依次提交两个人的修改，观察第二次保存是覆盖还是被拦住。

乐观并发控制：比较和写入必须是一件事

版本戳的完整流程并不复杂，但每一步都不能省。

下面是一段文档数据库风格的伪代码。关键不在某个产品的 API 名称，而在过滤条件里同时带上 id 和 version，并让版本递增与业务修改处于同一次原子更新中。

async function renameWorkflow(id, expectedVersion, newName) {
  const result = await workflows.findOneAndUpdate(
    { id, version: expectedVersion },
    {
      $set: {
        name: newName,
        updatedAt: new Date().toISOString()
      },
      $inc: { version: 1 }
    },
    { returnDocument: "after" }
  )
 
  if (

有些实现会先执行一次“查询当前版本”，确认相等后再发起普通更新。看上去逻辑一样，实际上两条语句之间又出现了新的时间缝隙：检查刚结束，另一位用户就可能写入；随后你的更新仍会覆盖对方。先查再写不是条件写入。 真正可靠的做法是让比较与修改在存储层成为不可分割的一步。

版本冲突与幂等不是一回事

版本戳防的是“拿旧状态覆盖新状态”。幂等键防的是“同一个请求因为超时或重试被执行两次”。一次支付请求既可能重复到达，也可能建立在过期订单上，因此两种保护经常要同时存在：用幂等键识别重复命令，用版本条件确认状态仍允许变化。

HTTP 里的版本戳：ETag 与 If-Match

条件更新并不只存在于数据库 SDK 中。HTTP 资源也可以把版本信息放进 ETag 响应头。客户端读取资源后保存这个值，修改时再通过 If-Match 交回服务器。

GET /workflows/flow-1024
 
200 OK
ETag: "flow-1024-v7"
Content-Type: application/json
 
{"name":"订单同步","retryLimit":3}

保存时，客户端明确提出条件：只有服务器当前的强实体标签仍与我手里的值匹配，才执行修改。

PUT /workflows/flow-1024
If-Match: "flow-1024-v7"
Content-Type: application/json
 
{"name":"订单同步","retryLimit":5}

如果别人已经把资源更新到新版本，服务器拒绝这次修改并返回 412 Precondition Failed。客户端随后可以展示差异、请求用户确认，或者在业务规则允许时把修改重新应用到最新版。

async function saveWorkflow(id, draft, etag) {
  const response = await fetch(`/workflows/${id}`, {
    method: "PUT",
    headers: {
      "Content-Type": "application/json",
      "If-Match": etag
    },
    body: JSON.stringify(draft)
  })
 
  if (response.status ===

这里还有一个容易忽略的边界：If-Match 使用强比较。带有 W/ 前缀的弱实体标签只说明两个表示在语义上大致等价，不适合拿来证明“这就是我刚才编辑的同一份字节级表示”。要用条件写入防止丢失更新，服务端应提供能参与强比较的 ETag。

版本戳不是只有一种长相

只要能在版本变化时稳定地换值，很多内容都可以充当版本戳。但不同方案携带的信息不同：有些能排序，有些只能判断相等；有些适合单写入口，有些适合离线多节点；有些生成便宜，却把风险转移给时钟或序列化过程。

1. 单调计数器：最适合单条记录的条件更新

每次成功更新都把 version 加一。它直观、紧凑，还能轻松看出同一条记录在同一条版本链上的先后。

{
  "id": "task-88",
  "status": "running",
  "version": 12
}

它不一定需要一台全局发号服务器。只要某条文档的条件检查和递增能在同一存储分区内原子完成，这个计数器就能服务于该文档。真正麻烦的是多个彼此断联的写节点都从 12 独立加到 13：两个不同内容会拿到同样的数字，单一计数器不再能描述并发分支。

2. 随机标识：擅长判等，不负责排序

每次修改都生成新的随机标识，节点无需共享计数器。它发生碰撞的概率可以做到极低，很适合把版本当成不透明令牌传递。

不过随机标识只回答“相同还是不同”。两枚不同标识摆在一起，通常看不出谁更新、更看不出两次修改是否并发。它也比小整数更占空间，日志和人工排查时不够亲切。

3. 内容哈希：让内容自己留下指纹

把选定字段按确定规则序列化，再计算哈希。相同输入会得到相同结果，任何节点都能独立验证内容是否变化。这对缓存校验、内容寻址和完整性检查很有用。

真正使用时必须先说清楚“哪些内容参与计算”。JSON 字段顺序、空白、数字格式、更新时间字段都会影响字节结果。如果两个节点的规范化规则不同，语义相同的文档也可能算出不同哈希。反过来，如果漏掉了会影响业务的字段，关键变化又可能没有反映在令牌中。

4. 物理时间戳：直观，却把正确性交给了时钟

更新时间看起来天然能排序，但多节点时钟会漂移、校时可能让时间向前或向后跳，同一时间精度内还可能发生多次写入。如果系统采用“时间更大者获胜”，一台走快的机器就可能长期压过另一台真正更晚发生的写入。

时间戳可以用于展示、审计和粗粒度排序；若要让它决定冲突胜负，就要认真处理时钟同步、精度、并列值和客户端伪造时间等问题。把 updatedAt 直接当作绝对因果顺序，通常过于乐观。

5. 组合修订标识：一枚令牌里放入多种线索

有些文档数据库会把“修订代数”和内容签名组合起来，例如 3-某段签名。前半部分说明这条分支走了几代，后半部分帮助识别具体修订。保存文档时需要带回旧修订标识，旧标识已经被替代就会触发冲突。

但这种修订标识不等于通用的版本控制历史，也不意味着代数大的分支一定包含代数小的任意分支。两条分支可以各自发展到第三代，仍然互不包含。它首先服务于复制、冲突检测和修订树管理，应用不能只截取前面的数字来决定业务上的“最新”。

下面的选择器不是替你拍板，而是逼你先把需求说清楚。切换条件，看看推荐方案为什么会变化。

从单主走向多主：数字为什么突然不够用了

在单主模式里，所有写入都经过同一个权威入口。主节点可以稳定地把版本从 7 推到 8，再推到 9；从节点只复制结果。此时计数器简单又有效。

多主模式换了一个目标：即使北京与上海之间的网络暂时中断，两地也要继续接收写入。可用性提高了，系统却失去了唯一的排队者。北京把版本 7 改成 8，上海也把自己手里的版本 7 改成 8。两条记录都叫“8”，内容却不同。

我们不能因为它们编号一样就说内容一致，也不能随便挑一个覆盖另一个。真正需要回答的是：

• 一个版本是否包含另一个版本之前的全部变化？
• 两个版本是否在互不知情的情况下各自发展？
• 如果是并发分支，应该保留、合并还是按业务规则决胜？

向量时钟记录“每个参与者知道了多少”

向量时钟给每个写入参与者保留一个计数位置。假设只有北京、上海、广州三个节点，一枚向量可以写成：

{ 北京: 2, 上海: 1, 广州: 0 }

它表达的是这条版本链已经包含北京的 2 次事件、上海的 1 次事件，还没有包含广州的事件。缺少的节点通常按 0 处理。

每次本地写入，可以按下面的顺序理解：

1. 先带上本次写入所基于的上下文，也就是客户端读到的向量；
2. 接收节点把已知向量逐项取最大值，吸收自己见过的历史；
3. 再把代表本次事件的那个节点计数加一；
4. 新内容与新向量一起保存。

例如北京在 {北京: 2, 上海: 1, 广州: 0} 上继续修改，就得到 {北京: 3, 上海: 1, 广州: 0}。如果广州只见过 {北京: 2, 上海: 1, 广州: 0}，随后离线修改，就会得到 {北京: 2, 上海: 1, 广州: 1}。这两个结果来自共同祖先，却各自多了一项对方没有见过的事件，因此它们并发。

比较规则：逐项看，而不是把数字相加

给定向量 A 和 B：

• 如果每个位置都有 A >= B，并且至少一个位置严格大于，那么 A 支配 B。A 包含 B 的历史，还多出了一些事件。
• 如果每个位置都相等，那么两枚向量代表相同的因果进度。
• 如果 A 在某些位置更大，B 又在另一些位置更大，那么两者并发。谁也没有完整见过对方的历史。

把向量里的数字相加再比较是错的。{北京: 4, 上海: 0} 和 {北京: 0, 上海: 5} 的总和一边是 4、一边是 5，但它们仍是并发分支；总和更大不能证明包含关系。

下面可以直接输入两枚三节点向量。试试“明确先后”“完全相等”和“并发分支”三个预设，再自己改动任意一项。

向量时钟也有成本

向量里需要保存参与者身份和计数。节点不断加入、退出，元数据可能越来越大；如果把每台临时机器都当作永久参与者，维护成本会很快失控。真实系统会限制参与者集合、截断旧信息，或采用更紧凑的因果元数据。

还有一点更重要：向量时钟只能判断因果关系，不能替应用决定内容。它能告诉你“这两份购物车并发修改了”，却不知道同一件商品数量应该相加、取最大值，还是以用户最后确认的值为准。冲突检测和冲突解决是两件事。

发现冲突之后，系统到底该怎么办

不存在一个适合所有数据的合并按钮。我们需要先看字段代表什么，再选择策略。

拒绝并让用户重读

后台流程配置、合同内容、文章正文很适合这种方式。系统拒绝旧版本保存，展示“服务器版”和“你的修改”，让用户确认。它牺牲了一点操作流畅度，却避免了自动合并猜错业务意图。

自动合并互不重叠的字段

如果甲只修改 retryLimit，乙只修改 callbackUrl，系统可以按字段合并。不过，“字段不同”不等于“一定独立”。回调地址和签名密钥可能必须成对更新；状态和完成时间也可能存在约束。自动合并之前，要把这些不变量写进规则和测试。

用领域规则合并

购物车可以把“添加商品”记录成操作，再合并不同节点上的增量；计数器可以使用专门的可合并数据结构；标签集合可以把新增与删除建模为不同操作。这样做比整份文档互相覆盖更贴近用户动作，但设计和存储成本也更高。

选择一个确定的胜者

最后写入胜出容易实现，也能让所有副本快速收敛。不过它只是稳定地丢掉一个版本，不代表业务上更正确。若胜负依赖物理时间戳，还要承担时钟漂移的风险。适合可重建的缓存、低价值状态或明确接受覆盖的字段，不适合余额、库存和不可逆审批。

暂存多个兄弟版本

系统也可以先保留所有并发叶子，让应用稍后合并。某些文档数据库复制时会为同一文档保留多个冲突修订，并以确定规则选出一个默认可见版本。所谓“胜者”只是默认读取结果，其他分支仍需要应用识别和处理；否则它们只是被藏起来，并没有真正解决。

自动化流程案例：旧看门狗不能终止新任务

版本戳在自动化系统里格外实用，因为任务状态总在异步变化。考虑下面这份任务文档：

{
  "id": "job-2048",
  "status": "running",
  "attempt": 2,
  "workerId": "worker-bj-17",
  "startedAt": "2026-08-11T02:10:00Z",
  "version": 12
}

看门狗在 02:15 读到版本 12，判断任务似乎超时。就在它准备写入 timed_out 时，执行节点已经完成任务，把状态改成 succeeded，版本递增到 13。如果看门狗只按任务 ID 更新，它会把已经成功的任务重新标成超时，甚至触发第三次执行。

可靠写法把状态和版本一起放进条件：

async function markTimedOut(jobId, expectedVersion) {
  const updated = await jobs.findOneAndUpdate(
    {
      id: jobId,
      status: "running",
      version: expectedVersion
    },
    {
      $set: {
        status: "timed_out",
        finishedReason: "租约到期"
      },
      $inc: { version: 1 }
    },
    { returnDocument: "after" }

这里同时核对 status 和 version 很有价值。版本保证整条文档没有在你不知情时变化，状态条件又把允许的状态迁移写得一目了然。即使将来某段代码忘记解释版本含义，存储层也不会让 succeeded 直接倒退到 timed_out。

如果任务涉及跨服务操作，例如先调用供应商接口、再更新本地状态，单条文档版本戳不能自动提供跨系统原子性。我们还需要幂等请求、发件箱、补偿动作或状态机约束。版本戳能守住自己的那次条件写入，却不能把网络另一端也拉进同一个事务。

把版本控制真正落进项目

一套能长期运行的版本机制，不只是在文档里多放一个字段。你还要把它贯穿读取、接口、更新、错误处理和观测。

常见误区清单

• 只在前端比较版本。 前端的判断之后仍可能发生新写入，最终条件必须落到数据库或资源服务器。
• 更新成功却没有换版本。 只要会影响后续决策的内容发生变化，令牌就必须一起变化。
• 把随机标识按字符串排序。 随机令牌只适合判等，字符大小没有业务时间含义。
• 把内容哈希当作秘密。 哈希用于识别内容，不等于加密，也不能替代访问控制。
• 用客户端时间决定胜负。 用户设备可能走快、走慢或被手动修改，不能自然成为全局权威时钟。
• 检测到冲突就永久失败。 冲突是正常并发现象，应用应该给出可恢复路径，而不是只抛一条技术错误。
• 假设版本戳替代所有事务。 它保护条件写入，却不自动保证多文档、多分区和外部服务之间的一致性。

练一练

场景题

一个流程编辑器把整份配置作为单文档保存。近期冲突率很高，日志显示多数冲突发生在“通知模板”和“重试策略”这两个互不相关的区域。你会怎样调整？

小结

版本戳解决的是一个很具体的问题：用户或程序准备写入时，它所依据的旧状态是否仍然有效。单条记录里，我们通常用计数器、修订标识或 ETag 做条件更新，并把比较、业务修改和版本变化放进一个原子操作。

到了多个独立写节点，单一数字无法表达并发分支，向量时钟这类因果版本会逐项记录不同参与者的进度。它能区分“包含旧历史”和“彼此并发”，但发现冲突之后，仍要由业务选择拒绝、合并、确定性选胜或保留兄弟版本。

最后记住一个实用判断：先问版本令牌要回答什么，再决定它长什么样。 只要判等，可以用不透明令牌；需要单链排序，计数器更直接；需要多节点因果关系，就要承担更丰富元数据的成本。选型不是追求最复杂，而是让系统在真正发生并发时，既不悄悄丢数据，也能给出清楚的恢复路径。