document/show?id=4cf8ce8a8aad6957ff00005b
答案 0 :(得分：9)
一般来说，我认为您应该谨慎地向客户端公开内部（例如数据库ID）。可以轻松地操纵URL，并且用户可以访问您不希望他拥有的对象。
对于特殊的MongoDB，对象ID甚至可能会显示一些额外的内部（参见here），即它们不是完全随机的。这可能也是一个问题。
除此之外，我认为没有理由不使用id。
答案 1 :(得分：7)
我普遍同意@ MartinStettner的回复。我想补充几点，主要是详细阐述他所说的话。是的，可以从ObjectId解码少量信息。如果有人将其识别为MongoDB ObjectID，则可以轻松访问。两个缺点是：
第一项的“正确”修复是实现某种真实的访问控制：1）用户必须使用用户名和密码登录，2）该对象与该用户名相关联，3）仅限应用程序向用户提供与该用户名相关联的对象。
MongoDB本身并不这样做;你将不得不依赖其他手段。也许你的web-app框架和/或一些临时访问控制列表（它本身可以在MongoDB中）。
但这里有一个“快速修复”，主要解决这两个问题：根据一个大的，高质量的随机数为记录创建一些其他“id”。
“大”需要多大？ 128位随机数具有3.4 * 10 ^ 38个可能的值。因此，如果您的数据库中有10,000,000个对象，则猜测有效值的人概率很小：3.4 * 10 ^ 31中的1。还不够好？使用256位随机数...或更高！
如何在文档中表示此数字？您可以使用字符串（将数字编码为十六进制或base64）或MongoDB的二进制类型。 （请参阅驱动程序的API文档，以了解如何将二进制对象创建为文档的一部分。）
虽然您可以在文档中添加一个新字段来保存它，但您可能还需要一个索引。因此文档大小更大，并且您在该索引上花费更多内存。以下是您可能没有的内容：只需将“真正随机ID”用作您的文档“_id”字段。因此，每个文档的大小只有一点点，你可以使用你[可能]那里的索引。