Laravel-MongoDB 中 _id 与 id 的 JSON 响应处理实践

背景介绍

在 Laravel 项目中集成 MongoDB 数据库时，开发者经常会遇到一个特殊问题：MongoDB 默认使用 _id 作为主键字段，而 Laravel 的 Eloquent ORM 则默认期望 id 作为主键。这种差异在 API 开发中尤为明显，特别是在返回 JSON 响应时。

问题本质

当使用 Laravel-MongoDB 扩展包（5.1.0 版本）时，模型内部会自动处理 _id 和 id 之间的转换。数据库层面存储的是 _id，但在模型层面，开发者可以通过 $model->id 或 $model->_id 两种方式访问主键，它们实际上指向同一个值。

然而，当我们将模型数据直接转换为 JSON 响应时，系统默认会将主键字段输出为 id 而非 _id。这对于已经基于 _id 构建的前端或移动应用可能造成兼容性问题。

解决方案演进

传统处理方式

在早期版本中，开发者需要手动处理这种转换：

$data = Model::all()->map(function($item) {
    return array_merge($item->toArray(), ['_id' => $item->id]);
});
return response()->json(['data' => $data]);

这种方式虽然可行，但增加了代码复杂度和维护成本。

Laravel-MongoDB 5.0+ 的改进

从 5.0 版本开始，Laravel-MongoDB 实现了更智能的字段映射机制：

1. 数据库层面仍使用 _id 作为主键
2. 模型层面透明转换 id 和 _id
3. JSON 序列化默认输出 id 字段

这种设计使 MongoDB 模型与其他 Eloquent 模型保持行为一致，减少了认知负担。

实际应用场景

假设我们有一个发票(Invoice)模型，需要返回给移动端 API：

return response()->json([
    'invoice' => Invoice::where('_user_id', '677bc826c707fd89b70ce9ed')->first()
]);

默认输出会包含 id 而非 _id：

{
  "invoice": {
    "_user_id": "677bc826c707fd89b70ce9ed",
    // 其他字段...
    "id": "677c3d001c41ec816d0d6a1f"
  }
}

高级解决方案

对于需要保持 _id 字段输出的场景，开发者有以下几种选择：

1. 模型属性转换

在模型中添加访问器：

class Invoice extends Model
{
    public function get_IdAttribute()
    {
        return $this->id;
    }
}

2. 资源转换层

使用 Laravel 的资源转换器：

class InvoiceResource extends JsonResource
{
    public function toArray($request)
    {
        return array_merge(parent::toArray($request), [
            '_id' => $this->id
        ]);
    }
}

3. 全局 JSON 序列化配置

覆盖模型的 toArray 方法：

class BaseMongoModel extends Model
{
    public function toArray()
    {
        $array = parent::toArray();
        $array['_id'] = $this->id;
        unset($array['id']);
        return $array;
    }
}

最佳实践建议

1. 新项目：建议遵循 Laravel-MongoDB 的默认行为，使用 id 作为主键标识
2. 已有项目迁移：
   • 评估前端/移动端对 _id 的依赖程度
   • 考虑在 API 网关层进行字段转换
   • 或逐步迁移到 id 字段
3. 性能考量：大量数据转换可能影响性能，应在适当层级处理

总结

Laravel-MongoDB 在 5.0 版本后的主键处理机制提供了更好的 Eloquent 一致性，同时也保留了灵活性。开发者可以根据项目需求选择最适合的字段映射策略，平衡兼容性与代码整洁度。理解这一机制有助于构建更健壮的 MongoDB 应用架构。