ObjectId不能直接用作全局唯一ID，因其仅在单集合内唯一、依赖本地环境易致碰撞、人类不可读、跨系统需额外序列化；UUID（v4/v7）更适合作为全局唯一可读ID。
为什么不能直接用 ObjectId 当全局唯一ID
很多人默认把 _id 字段当成“全局唯一标识”，但实际中容易踩坑：它只在单个集合内保证唯一性（MongoDB 不校验跨集合重复），且生成依赖本地时间戳 + 机器标识 + 进程 ID + 自增计数器——如果应用部署在容器或无状态环境中（比如 Kubernetes Pod 重启、多实例并行写入），自增计数器可能重置，极端情况下出现碰撞风险（虽极低，但金融/订单类场景不可接受）。
更关键的是：ObjectId 是 12 字节二进制值，人类不可读、不便于日志追踪和 API 调试；导出到其他系统（如 Kafka、ES）时还需额外序列化为字符串，增加转换成本。
- 不要依赖
ObjectId的“全局唯一”语义，尤其当数据需跨集合关联或对外暴露 - 若业务要求“全局唯一+可读+可预测长度”，
UUID（v4 或 v7）是更稳妥的选择 - MongoDB 5.0+ 原生支持
UUID类型（binary subtype 0x04），比存成字符串更省空间、索引效率更高
如何正确存储 UUID 并设为 _id
直接把 UUID 字符串赋给 _id 看似简单，但会损失性能和类型语义。推荐方式是使用 MongoDB 的二进制 UUID 类型，并在驱动层统一处理。
- Node.js 驱动中，用
new Binary(uuid.parse("..."), Binary.SUBTYPE_UUID)构造，而不是字符串 - Python PyMongo 中，用
uuid.UUID("...")实例直接赋值，驱动自动识别为Binarysubtype 4 - 务必在集合创建时显式设置
_id索引，避免驱动自动创建字符串型索引（否则无法利用 UUID 类型优化） - 查询时也必须用相同类型匹配：
{ _id: new Binary(..., 4) }，混用字符串会导致全表扫描
示例（Node.js）：
const { Binary, ObjectId } = require('mongodb');
const { v4: uuidv4 } = require('uuid');
const doc = {
_id: new Binary(Buffer.from(uuidv4().replace(/-/g, ''), 'hex'), 4),
name: 'user-abc'
};
什么时候该用自定义 ObjectId 替代 UUID
UUID 优势明显，但不是银弹。如果你的系统有强时间序需求（如按 ID 排序获取最近 N 条记录）、对存储体积敏感（UUID 占 16 字节，ObjectId 仅 12 字节），或已有大量基于 ObjectId 的上下游逻辑，可以考虑自定义生成策略。
- 不要手写
ObjectId字符串再转为对象（如new ObjectId("...")），这不解决唯一性问题 - 可行做法：用服务端统一发号器（如 Snowflake）生成 96 位整数，拆成 3 段填入
ObjectId的 time/machine/pid/inc 字段（需自行实现序列化逻辑） - 更轻量方案：用
Date.now()+Math.random()+ 进程唯一标识拼接后取哈希，再截取 12 字节作为ObjectId—— 本质是伪造，但可控性比原生高 - 注意：所有自定义方案都绕不开“分布式协调”问题，若没做跨节点同步，仍可能重复
建模时最容易被忽略的兼容性细节
UUID 类型在不同 MongoDB 版本和驱动间行为不一致，很多线上事故源于此。
- MongoDB $oid JSON 表达，shell 或 Compass 查看时显示为乱码二进制，调试困难
- 某些旧版驱动（如 PyMongo _id，也无法被
ObjectId构造函数识别，导致find_one({"_id": ObjectId(...)})查不到 - 聚合管道中若对 UUID 字段做
$toString，结果是 Base64 编码而非十六进制字符串，前端解析易出错 - 备份恢复时，mongodump/mongorestore 默认不保留 binary subtype，UUID 可能变成普通
BinData，需加--binaryAsBase64参数
真正麻烦的从来不是选 UUID 还是 ObjectId，而是整个链路——从 SDK、ORM、监控埋点、日志采集到下游数仓——是否全部对齐了类型语义。漏掉一环，就可能在某个凌晨三点查不到那条关键订单。
