Couch DB更新文档字段保留旧数据：多端复制场景问询

这个场景太典型了——多个用户修改同一个父文档里的不同子项，默认的文档级冲突解决只会保留其中一个版本，肯定会丢数据。要实现不丢失各自修改的字段，核心是做子文档级的合并，而不是整个文档覆盖。下面给你一步步说怎么实现：

核心问题拆解 #

默认情况下，CouchDB/PouchDB的冲突解决是基于整个文档的：当两个版本的文档_id相同但_rev不同时，会默认选择最后更新的版本（或者让你手动处理）。但这里A和B修改的是数组里不同的子对象（A改id=1，B改id=2），所以我们需要自定义逻辑，把两个版本里的子项按id匹配，保留各自的修改。

具体实现方案 #

1. 在PouchDB客户端处理冲突（适合客户端之间的复制） #

如果是两个PouchDB客户端之间直接复制，你可以在复制过程中指定自定义冲突处理函数，合并两个版本的people数组：

// 假设A的本地库叫"userA-db"，B的叫"userB-db"
PouchDB.replicate('userA-db', 'userB-db', {
  conflict: function(docA, docB) {
    // docA是A修改后的版本，docB是B本地已有的版本
    const mergedPeopleMap = {};

    // 先把两个版本的子项都存入Map，用id作为唯一键
    [docA, docB].forEach(doc => {
      doc.people.forEach(person => {
        // 这里如果有updated_at字段，优先用它判断最新版本；没有的话用文档的_rev
        const existing = mergedPeopleMap[person.id];
        if (!existing || doc._rev > existing._docRev) {
          mergedPeopleMap[person.id] = {
            ...person,
            _docRev: doc._rev // 临时存一下父文档的版本，用于判断新旧
          };
        }
      });
    });

    // 把Map转回数组，去掉临时的_docRev字段
    const mergedPeople = Object.values(mergedPeopleMap).map(({ _docRev, ...person }) => person);

    // 返回合并后的新文档，注意要保留_id，生成新的_rev会由数据库自动处理
    return {
      _id: docA._id,
      people: mergedPeople
    };
  }
}).on('complete', (info) => {
  console.log('复制完成，冲突已合并:', info);
}).on('error', (err) => {
  console.error('复制出错:', err);
});

2. 在CouchDB服务端设置统一冲突解决逻辑（适合多客户端同步到服务端） #

如果是所有客户端都同步到同一个CouchDB服务端，建议在服务端的设计文档里定义全局的冲突解决函数，这样不管哪个客户端同步，都会用统一的规则合并：

首先创建一个设计文档（可以通过CouchDB的API或者Fauxton界面上传）：

{
  "_id": "_design/people-conflict-resolver",
  "language": "javascript",
  "updates": {
    "merge-people": "function(doc, req) {
      // 获取所有冲突的文档版本
      const conflictIds = req.conflicts;
      if (!conflictIds || conflictIds.length === 0) {
        return [doc, 'No conflicts to resolve'];
      }

      // 拉取所有冲突版本的文档
      const allVersions = [doc].concat(conflictIds.map(id => req.db.get(id)));
      const mergedPeople = {};

      allVersions.forEach(version => {
        version.people.forEach(person => {
          // 用每个父文档的_rev判断版本新旧，也可以换成子项的updated_at字段
          if (!mergedPeople[person.id] || version._rev > mergedPeople[person.id].parentRev) {
            mergedPeople[person.id] = {
              ...person,
              parentRev: version._rev
            };
          }
        });
      });

      // 更新原文档的people数组，清除冲突标记
      doc.people = Object.values(mergedPeople).map(({ parentRev, ...p }) => p);
      delete doc._conflicts;

      return [doc, 'Successfully merged people conflicts'];
    }"
  }
}

之后，当服务端检测到冲突时，可以调用这个更新函数来合并版本：

curl -X POST http://your-couchdb-url/db-name/_design/people-conflict-resolver/_update/merge-people/doc-id

验证合并效果 #

不管用哪种方式，最终合并后的文档应该是：

{
  "people": [
    {"id": 1,"dept_id": 3,"user": "A"},
    {"id":2 ,"dept_id": 4,"user": "B"},
    {"id": 3,"dept_id": 1,"user": "C"}
  ]
}

额外注意事项 #

• 如果出现同一个子项被多个用户修改（比如A和B都改了id=1的dept_id），上面的逻辑会保留版本更新的那个。如果需要更严谨的处理，可以给每个子项添加updated_at时间戳字段，合并时用时间戳判断新旧，或者提示用户手动解决。
• 双向复制时，确保两边都应用相同的冲突解决逻辑，避免重复触发冲突。
• 测试时可以先在本地模拟冲突，再验证合并结果是否符合预期。

内容的提问来源于stack exchange，提问作者Karthik