mongodb 的 objectid 是分布式 id 的高效实现，无需中心服务；它由时间戳、机器进程标识和原子计数器组成12字节id，保证全局唯一、时间有序、高并发安全。
MongoDB 自带的 ObjectId 就是分布式 ID 的高效实现，无需额外开发或部署中心服务。 它在插入文档时自动生成，满足全局唯一、时间有序、高并发安全等核心要求。直接用，别自己造轮子。
为什么 ObjectId 能天然支持分布式生成
它不依赖网络协调、不查数据库、不发 RPC，每个客户端或 mongod 实例都能独立生成：
- 前 4 字节是秒级时间戳（
timestamp），保证新 ID 大致按时间递增 - 中间 5 字节含机器标识（3 字节）+ 进程 ID（2 字节），不同机器/进程不会撞
- 最后 3 字节是每进程内原子自增计数器（
counter），单进程每秒最多支撑约 1677 万 ID - 所有字段拼接为 12 字节二进制，转成 24 位十六进制字符串（如
"5fd049327fbb28868f4660a5"）
ObjectId 在写入时如何避免重复和性能瓶颈
重复只可能发生在同一秒、同一进程、计数器溢出时——但实际极难触发，因为：
- 计数器是
AtomicInteger（Java 驱动）或线程局部变量（其他语言），无锁自增 - 驱动层默认在
insertOne()前自动生成_id，不经过网络往返 - 如果显式传入
ObjectId，需确保不重复；若传null或省略，驱动自动补全 - 注意：不要在业务代码里手动 new
ObjectId(new Date())，会丢失机器/进程信息，退化为纯时间+随机，增大碰撞风险
什么时候不该直接用 ObjectId 作业务 ID
它适合做文档主键，但不等于适合所有业务场景：
- 需要毫秒级严格递增（比如金融流水号）→
ObjectId是秒级，且计数器重置后可能回绕 - 要求 ID 更短（如 16 位数字）或纯数字 →
ObjectId固定 24 字符十六进制，无法压缩 - 需隐藏生成时间（防时间泄露）→ 前 4 字节明文时间戳，一解码就知道创建秒数
- 业务强依赖“租户前缀”或“渠道编码”→
ObjectId无业务语义，得自己拼接或换方案
真正容易被忽略的是：很多团队在应用层硬套 Snowflake 逻辑去生成 ID，再塞进 MongoDB，结果既没获得 Snowflake 的毫秒精度，又丢了 ObjectId 的零配置优势。只要你的业务能接受秒级有序、24 字符长度、不暴露毫秒细节，ObjectId 就是最轻量、最可靠的选择。
