MongoDB不能直接支持OT协同编辑，因其缺乏操作意图记录、因果依赖表达和自动转换能力，仅能作为带版本号的原子存储；需在应用层实现操作抽象、transform逻辑及一致性保障。
MongoDB 本身不内置 OT 算法或版本向量支持，直接用 updateOne + $set 做多人编辑必然导致覆盖丢失。要支撑协同办公编辑，必须在应用层补全操作抽象、转换逻辑和一致性保障，MongoDB 只承担「带版本号的原子存储」角色。
为什么不能直接用 MongoDB 的 version 字段做冲突检测
MongoDB 的文档级 _id 或自增 version 字段只能标识“谁最后写”，无法表达操作间的因果依赖。比如两个用户同时对同一字段执行 { $inc: { count: 1 } }，即使加了 version: 5 条件，也无法区分这两个 inc 是并发还是串行——更无法决定它们在最终状态中是否该叠加、抵消或重排序。
-
findAndModify配合version可防止脏写，但解决不了位置敏感型操作（如富文本插入）的偏移错位 - 单纯用
updatedAt时间戳排序，在网络延迟下极易产生逻辑倒置（B 操作时间戳早于 A，但实际语义应在 A 之后） - 没有向量时钟（
vectorClock）或 Lamport 时间戳，就无法构造操作间的偏序关系，OT 的transform函数失去输入依据
oplog 不是 OT 的替代品，它只记录结果，不保留意图
MongoDB 的 oplog 是变更日志，内容类似 { "ts": ..., "op": "u", "o2": { "_id": ... }, "o": { "$set": { "content": "new" } } }。它记录“改成了什么”，但从不记录“想插在哪”“删的是哪一段原始字符”——而 OT 正是靠这些原始意图（pos, text, type: 'insert'）才能做转换。
- 你无法从
oplog中还原出用户 A 在位置 3 插入"x"、用户 B 在位置 2 删除"a"这类带上下文的操作描述 - 服务端若只基于
oplog回放，遇到并发插入会直接得到错误偏移：A 插入后文档变长，B 的原始位置 2 已不是原意位置 - 真正需要持久化的不是最终值，而是客户端提交的原始
Op对象，例如{ type: 'insert', pos: 2, text: 'b', src: 'user-b', seq: 7, v: 4 }
如何用 MongoDB 存储 OT 所需的元数据
关键不是存文档快照，而是存可转换、可追溯的操作流。推荐结构如下：
db.operations.insertOne({
_id: ObjectId("..."),
docId: "sheet-123",
op: { type: "insert", pos: 5, text: "hello" },
src: "user-a",
seq: 12,
v: 8,
timestamp: ISODate("2026-04-18T02:45:11.221Z"),
transformedBy: ["user-b:9", "user-c:3"] // 记录哪些操作已参与过此 op 的转换
})
-
v字段必须由客户端生成并递增，服务端只校验（如拒绝v < currentVersion的旧操作），不自增 - 每个操作单独存为一条文档，而非聚合到主文档里——便于按
docId+v查询历史、做增量同步 - 避免使用
$push往数组里塞操作，MongoDB 数组更新非原子，高并发下易丢操作 - 为
{ docId: 1, v: 1 }建复合索引，支撑快速拉取某文档从某版本起的所有操作
客户端必须自己实现 transform，MongoDB 不提供这个函数
所谓“MongoDB 支持 OT”，本质是它能可靠存下 Op 和其元数据，但 transform(OA, OB) 的逻辑完全在客户端/服务端业务代码里。例如两个插入操作冲突：
- A 提交
{ type: 'insert', pos: 2, text: 'a' }，当前文档长度为 5 - B 提交
{ type: 'insert', pos: 2, text: 'b' }，但此时 B 的本地视图仍是长度 5 的旧状态 - 当 B 收到 A 的操作后，需调用
transform(B.op, A.op) → { pos: 3, text: 'b' }，再应用到本地 - 这个
transform函数必须和服务器校验逻辑一致，否则会出现“客户端转了，服务器没转”导致状态分裂
最容易被忽略的一点：transform 不是纯函数，它依赖双方操作的相对顺序与类型组合。插入-删除、删除-插入、插入-插入的规则完全不同，且必须双向可逆（transform(A,B) 和 transform(B,A) 要能共同收敛）。这部分逻辑一旦写错，协作状态就会不可逆地发散，而 MongoDB 只忠实地存下错误的结果。
