解读

在国内真实落地场景中，MongoDB 的 ObjectId 是 12 字节二进制，而 CouchDB 强制要求 _id 必须是 UTF-8 合法字符串。如果直接把 ObjectId 当二进制塞进 CouchDB，会触发 “doc id must be string” 校验失败；若直接 toString() 又可能因长度、大小写、URL 特殊字符导致 404 找不到文档 或 复制冲突。因此，面试官想考察的是：

1. 你是否理解两种 _id 的底层约束差异；
2. 能否给出 可逆、可排序、对中文运维友好 的映射方案；
3. 是否兼顾 存量数据一次性迁移 与 增量双写平滑切换 的国内上线节奏。

知识点

1. MongoDB ObjectId 结构：4 字节时间戳 + 5 字节随机值 + 3 字节计数器，总 12 字节，默认展示为 24 位十六进制字符串。
2. CouchDB _id 规则：必须是字符串，≤ 65536 字节，建议避免 + / _ . 等 URL 保留字符，否则需二次 encode，增加 30% 长度。
3. 国内合规要求：部分金融、政务项目要求 可审计、可回滚，因此映射算法必须 双向可逆，不能丢随机值。
4. CouchDB 视图排序：_id 作为视图主键，若需 时间范围查询，应保证 字典序≈时间序。
5. 双主复制冲突：若迁移期间 MongoDB 与 CouchDB 同时写入，需确保 同一业务主键 不会生成两个不同 _id，否则 CouchDB 多主复制会保留两份文档，需 conflict 处理脚本。

答案

我采用 “24 位十六进制保留 + 冲突隔离前缀” 的兼容方案，分三步落地：

1. 可逆映射：ObjectId 原样转 24 位 hex 字符串，直接作为 CouchDB _id，不做 base64 缩短，保证 1:1 可逆，满足审计。
2. URL 安全校验：hex 字符串本身只含 0-9a-f，天然 URL 安全，无需二次 encode，避免国内网关 Nginx 400 错误。
3. 双写隔离：增量阶段在 CouchDB id 前追加 **“m”** 前缀，表示 MongoDB 来源；CouchDB 新生成文档仍用 uuid v4 的 32 位 hex，避免 同号冲突。迁移结束后通过 _changes 接口 去掉前缀，完成 无缝切换。
4. 时间序优化：若业务需按创建时间范围查，可在 CouchDB 设计视图 emit(doc._id.substr(2,8), null)，利用 hex 前 8 位就是 Unix 时间戳 的特性，字典序即时间序，无需额外索引。
5. 回滚预案：在 MongoDB 新增 couchId 字段，反向记录 CouchDB _id；若迁移失败，可通过 mongoexport + 自定义脚本 在 2 小时内回滚，满足国内 上线窗口≤4 小时 的运维规范。

拓展思考

1. Snowflake 场景：如果原 MongoDB 已用 Snowflake 字符串 _id，则无需 hex 转换，但需检查 长度+特殊字符，必要时做 urlencode，并评估 CouchDB 视图键长度 对性能的影响。
2. 分片集群：CouchDB 3.x 在国内公有云常以 3 节点 + 2 代理 部署，若 id 前缀过于集中（如全 “m”），可能引发 热点分片，此时可把 ObjectId 第 5-8 字节 作为 哈希后缀，打散到不同分片。
3. 移动端同步：若后续使用 PouchDB + 微信小程序，24 位 hex _id 仍嫌过长，可在 首次同步 时建立 localStorage 映射表，把 hex 缩成 8 位 CRC62，但需接受 不可逆 风险，并征得 数据治理小组 书面同意，避免 金融审计 不通过。