仅靠 _id 和时间戳无法实现可靠版本控制，因会丢失操作人、修改字段、并发冲突等上下文，且覆盖写入导致无法回滚至任意中间状态；推荐采用主集合存最新版、独立历史集合存完整快照（含 docid、version、data、operator、timestamp 等元数据）的方案，确保可审计、可回溯、可精准恢复。
为什么不能只靠 _id 和时间戳做版本控制
直接在文档里加 version 字段并每次 $inc，看似简单，但会丢失变更上下文：谁改的、改了哪些字段、是否被覆盖、有没有并发冲突。更关键的是，这种做法无法回滚到任意中间状态——因为旧值已被覆盖。真正需要版本控制的场景（如合同、配置、用户档案），必须保留完整历史快照，而不是仅靠当前文档推断。
- 单文档
version字段只适合乐观锁校验，不等于版本历史 -
updatedAt时间戳无法区分同一秒内的多次修改 - 软删除 + 覆盖写入会导致历史不可追溯，审计失败
用独立历史集合实现可回溯版本（推荐方案）
核心思路是：主集合只存最新版，所有变更都以完整快照形式写入 xxx_history 集合，并带元数据。这样读最新版快、查历史全、回滚准。
- 主集合（如
documents）保持轻量，只含_id、data、version、updatedAt - 历史集合（如
documents_history）每条记录含：docId（指向主文档）、version、data（完整快照）、operator、timestamp、reason（可选） - 写操作必须原子化：先插入历史记录，再更新主文档；任一失败则整体回退（应用层事务或两阶段提交）
示例插入历史记录：
db.documents_history.insertOne({
docId: ObjectId("..."),
version: 5,
data: { title: "v5", content: "...", status: "published" },
operator: "user_123",
timestamp: new Date(),
reason: "fix typo in title"
})
如何安全地更新并生成新版本
避免在应用层手动计算 version 或拼接 data，容易漏字段或破坏结构。应统一用 MongoDB 的 $set + 应用层深拷贝来生成快照。
- 读取当前主文档时，务必用
projection排除_id等系统字段，防止历史快照中混入不可变标识 - 更新前先用
findAndModify或findOneAndUpdate带returnNewDocument: false获取旧版，用于比对和存档 - 不要依赖客户端传来的
version值做校验——它可能被篡改；服务端应基于db.collection.countDocuments({docId: ...})或主文档的version字段做递增校验
查询特定版本或时间点的数据
历史集合天然支持按 docId + version 精确查询，也支持按时间范围扫描。但注意索引设计直接影响性能。
- 必须在
documents_history上建复合索引：{ docId: 1, version: -1 }（支持最新版优先查） - 如需按时间回溯，补建：
{ docId: 1, timestamp: -1 }；否则sort({timestamp: -1}).limit(1)可能全表扫 - 避免用
$where或聚合管道中的$objectToArray做字段级差异分析——太慢；差异比对应在应用层完成
查第 3 版本：
db.documents_history.findOne({ docId: ObjectId("..."), version: 3 })
版本控制真正的复杂点不在写入逻辑，而在于「什么时候该存全量快照 vs 差异补丁」——业务语义决定存储粒度。比如配置项变化小，可用 diff 存储节省空间；但法律文本必须存全量，否则哈希校验和司法采信会出问题。别为了“看起来像 Git”而忽略业务约束。
