使用MERN栈开发食谱应用：URL中用MongoDB ObjectId是否为不良实践？

首先明确：直接用MongoDB自动生成的ObjectId作为URL中的标识，不算严格意义上的「不良实践」，但在作品集项目中，改用独立的公开ID会显得更专业，也能规避一些潜在问题。

一、使用MongoDB ObjectId的优缺点 #

优点 #

• 实现成本极低：无需额外代码逻辑生成和存储ID，MongoDB自动处理，适合快速开发。
• 全局唯一性：ObjectId基于时间戳、机器标识等生成，重复概率几乎为0，不用担心冲突。

缺点 #

• 暴露数据库实现细节：URL里出现507f1f77bcf86cd799439011这类格式的ID，懂行的面试官一眼就能看出你用的是MongoDB，会让URL显得不够「用户友好」和「抽象化」。
• 潜在信息泄露：ObjectId包含时间戳，有心人可逆向出文档创建时间，虽然食谱分享这类公开场景影响不大，但作为作品集，细节优化能加分。
• 可读性差：相比短ID或语义化标识，ObjectId过长，用户很难记忆或手动输入。

二、为什么建议为作品集项目使用独立公开ID？ #

对于求职作品集来说，细节决定成败，改用独立公开ID能体现你对「API设计最佳实践」和「用户体验」的考量：

• 符合RESTful设计原则：资源标识应与底层存储解耦，不暴露数据库实现细节，让URL更具抽象性。
• 提升用户体验：可生成短ID（如自增整数、短UUID、自定义字母数字ID），结合recipeName实现语义化友好URL，比如../recipe/classic-chocolate-cake/cc123，既美观又实用。
• 灵活性更高：未来若切换数据库（如从MongoDB换成PostgreSQL），无需修改URL结构，避免破坏现有链接可用性（对SEO和用户收藏的链接很重要）。

三、实现独立公开ID的简单方案 #

在MERN栈中，你可以这么做：

1. 在MongoDB的Recipe模型中添加publicId字段，设为唯一索引：

const recipeSchema = new mongoose.Schema({
  name: String,
  publicId: {
    type: String,
    unique: true,
    required: true
  },
  // 其他字段...
});

2. 创建食谱时自动生成publicId，比如用short-uuid生成短标识：

const shortUuid = require('short-uuid');

const newRecipe = new Recipe({
  name: req.body.name,
  publicId: shortUuid.generate(),
  // 其他字段赋值...
});
await newRecipe.save();

3. 路由中用publicId替代_id查询资源：

app.get('/recipe/:recipeName/:publicId', async (req, res) => {
  const recipe = await Recipe.findOne({ publicId: req.params.publicId });
  // 处理响应逻辑...
});

总结 #

如果是快速原型开发，用MongoDB的ObjectId完全没问题，但作为求职作品集，花点时间实现独立公开ID，能展示你对最佳实践的理解，让项目更接近生产级应用标准，给面试官留下更好的印象。

内容的提问来源于stack exchange，提问作者Macubi