从请求中解析ObjectId并不困难（因此我不确定为什么会出现问题？）。如果目标是创建可键入的URL，那么拥有更短且更“友好”的URL将很有价值。
您不能在分片的MongoDB设置中采用保证唯一的12个字节的数字，并将其压缩为少于12个字节，并且保证它是唯一的（例如，您提到的7个字符以下）。
从文档中，MongoDB ObjectId包括：
- 4字节的时间戳
- 一个3字节的机器标识符
- 一个2字节的进程ID
- 和一个3字节计数器。
因此，您要么需要牺牲ObjectId的一部分（并因此进行分片），要么设计索引的替代ID创建格式。
虽然您可能会散列ID，但再次可能会产生您希望为其编码的冲突（再次，您不能将12个字节缩减为4个字节并保证唯一性）。并且，如果可能发生冲突（并且减少可用位数的总和），那么无论如何您都将需要某种二级表（并且需要创建一个索引来将生成的ID转换为ObjectId）
。
结果选项：
- 删除通常有效的位-如果这样做， 请勿 将集合分片
- 设计自己的独特ID解决方案（如果位于网络农场中，则最终看起来可能与MongoDB非常相似以处理唯一性）
- 将ObjectId用作长整数并对其运行缩短的算法（由于它超出了Javascript的53位数字精度，因此需要首先分解为较小的块），例如，尝试使用该算法=对其进行编码（最终会在周围17个字符）
- 使用其他更短但更独特的名称作为您文档的ID
- 最简单：只需接受ID长即可。:)
（尚不清楚为什么浏览器需要进行此转换-为什么要具有文档的ObjectID？）
