一个有点主观的问题，但我对在客户端使用 mongodb _ids 有一些担忧。我最好使用 s52ruf6wst 或 xR2ru286zjI 之类的东西来获取 RESTful 资源并处理小项目集合。
1）我开始依赖后端数据库的专有实现（_id 字段名称和实现）。如果我坚持使用这个 _ids，以后就很难替换后端数据库。
2）我有包含 mongo _ids 的巨大丑陋 URL（即使对于 REST 端点 - 我不喜欢它）
3）对于黑客和“好奇的用户”来说，使用哪个后端数据库变得很明显。
正如我所见，大多数 Web 应用程序都使用自己的 id、uid、uuid 外观约定，我会说它看起来更专业（比使用 db 供应商的简单丑陋的实现）。
所以问题是什么时候最好使用标准的 mongo _ids 并在后端和前端使用它们？可以做些什么来改善这种情况？
什么时候最好使用标准的 mongo _ids
总是。除非你根本不喜欢它。但是您的个人偏好与安全性无关。Mongo 的对象 id本质上并不比任何其他标识符类型（整数、UUID 等）更安全。
ObjectID 设计为在您的集群中是唯一的，这非常重要，因为 mongodb 是一个分布式数据库。它还有一个很好的特性：值随时间单调递增。这个属性可能对你有用，也可能没用。
1）我开始依赖后端数据库的专有实现（_id 字段名称和实现）。如果我坚持使用这个 _ids，以后就很难替换后端数据库。
这就是抽象层、框架和 ODM (ORM) 的用武之地。它们提供了一个标准化层（即 Doctrine 2）来查询多种不同类型的数据库。例如，根据您使用的数据库，在id许多 ORM 中进行翻译。_idIDid
如前所述，ObjectId它没有固有的安全缺陷，它通常对其他用户来说甚至没有那么有用，因为即使它ObjectId有一个时间部分，这个时间部分也不能轻易地用来决定下一个对象是什么（不像自动递增ID）。可靠地做到这一点的唯一方法是测试到目前为止的所有时间和所有 pid 数字以检测是否存在隐藏对象。因此，抓取ObjectIdURL 根本不是一件容易的事，事实上，正是由于这个原因，它对 SEO 也不是很友好。但是是的，他们可以知道您使用的是什么数据库。
话虽如此，是的，它们很丑，但正如@Sergio 所说，它们又长又丑，是独一无二的。自己做也一样糟糕。我想你可以通过 base64 对ObjectId.
但是我不确定你是否真的需要它。