Laravel模型获取器？获取器怎样定义使用？-Laravel-PHP中文网

Laravel模型获取器用于在读取属性时动态格式化数据，如拼接姓名、格式化日期等，通过get{AttributeName}Attribute方法实现，配合$appends可自动包含在JSON输出中，需避免N+1查询和复杂逻辑以保证性能。

laravel模型获取器？获取器怎样定义使用？

Laravel模型获取器（Accessors）是框架提供的一种机制，用于在从数据库获取模型属性时，对这些属性进行自动转换或格式化。简单来说，它们允许你在不改变数据库实际存储值的情况下，动态地修改属性的呈现方式。定义获取器通常通过在模型中创建特定命名格式的方法来实现，使用时就像访问模型的普通属性一样。

解决方案

Laravel模型获取器本质上是模型类中的特殊方法，它们在你尝试访问某个属性时被自动调用。这种机制非常灵活，可以用于多种场景，比如格式化日期、拼接字符串、计算派生属性，甚至是进行简单的加密或解密操作（尽管对于敏感数据，更推荐使用专门的加密服务）。

要定义一个获取器，你需要在你的模型中创建一个方法，遵循

get{AttributeName}Attribute

登录后复制

的命名约定。其中，

{AttributeName}

登录后复制

是你想要转换的属性的“驼峰式”命名版本。例如，如果你有一个

first_name

登录后复制

和

last_name

登录后复制

字段，你可能想要一个

full_name

登录后复制

获取器来将它们拼接起来。

这个方法会接收原始属性值作为参数（如果存在），并返回你希望最终呈现的值。当你在模型实例上访问

full_name

登录后复制

属性时，Laravel就会自动调用

getFullNameAttribute

登录后复制

方法，并返回它的结果。

举个例子：

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    /**
     * 获取用户的全名。
     *
     * @return string
     */
    public function getFullNameAttribute()
    {
        // 这里可以加入一些业务逻辑，比如判断first_name或last_name是否为空
        // 避免直接拼接可能导致多余空格的情况。
        $firstName = $this->attributes['first_name'] ?? '';
        $lastName = $this->attributes['last_name'] ?? '';

        if (empty($firstName) && empty($lastName)) {
            return '匿名用户';
        } elseif (empty($firstName)) {
            return $lastName;
        } elseif (empty($lastName)) {
            return $firstName;
        }

        return "{$firstName} {$lastName}";
    }

    /**
     * 获取用户是否是管理员。
     * 假设数据库中有一个 `is_admin` 字段存储 0 或 1。
     *
     * @return bool
     */
    public function getIsAdminAttribute()
    {
        return (bool) $this->attributes['is_admin'];
    }

    /**
     * 获取格式化后的创建日期。
     *
     * @return string
     */
    public function getCreatedAtFormattedAttribute()
    {
        // 确保 created_at 是 Carbon 实例，Laravel默认会做这个转换
        return $this->created_at ? $this->created_at->format('Y年m月d日 H:i') : 'N/A';
    }
}

登录后复制

定义好获取器后，你就可以像访问普通模型属性一样使用它们了：

$user = User::find(1);

echo $user->full_name; // 会调用 getFullNameAttribute()
echo $user->is_admin;  // 会调用 getIsAdminAttribute()
echo $user->created_at_formatted; // 会调用 getCreatedAtFormattedAttribute()

登录后复制

这种方式让模型变得更加“智能”，它能根据业务需求，在数据离开模型时提供更友好的格式，而不需要在控制器或视图层重复处理这些格式化逻辑。

Laravel模型获取器与修改器的区别是什么？

谈到Laravel模型的属性转换，除了获取器（Accessors），我们通常还会提到修改器（Mutators）。这两者其实是相辅相成的，但作用的方向截然不同，理解它们的区别对于合理组织代码非常关键。

简单来说，获取器是在你从模型中“取出”数据时进行转换的。它就像一个过滤器，在你读取

Model->attribute

登录后复制

的时候，悄悄地把原始数据处理一番，再给你看处理后的结果。它的目的是为了数据的展示或计算，不会影响数据库中实际存储的值。比如，你可能有一个

price

登录后复制

字段存储的是分，但你希望在显示时自动转换成元。

而修改器则是在你往模型中“存入”数据时进行转换的。当你设置

Model->attribute = $value

登录后复制

时，修改器会介入，对

$value

登录后复制

进行预处理，然后才将处理后的值写入模型的

attributes

登录后复制

数组，最终保存到数据库。它的目的是为了数据的存储规范化、加密或者其他入库前的处理。比如，你可能希望用户输入的密码在保存前自动进行哈希加密。

让我们通过代码对比一下：

获取器示例 (Accessor):

// 在 User 模型中
public function getEmailDomainAttribute()
{
    // 假设 email 字段是 'john.doe@example.com'
    return explode('@', $this->attributes['email'])[1] ?? null;
}

// 使用时
$user = User::find(1);
echo $user->email_domain; // 输出 'example.com'

登录后复制

这里，

email_domain

登录后复制

并不是数据库中的一个字段，而是根据

email

登录后复制

字段动态计算出来的。

修改器示例 (Mutator):

// 在 User 模型中
public function setPasswordAttribute($value)
{
    // 在保存密码前自动进行哈希加密
    $this->attributes['password'] = bcrypt($value);
}

// 使用时
$user = new User;
$user->password = 'secret'; // 调用 setPasswordAttribute()，实际存入的是哈希值
$user->save();

登录后复制

这里，当你给

password

登录后复制

属性赋值时，修改器会自动将其加密后再存储，确保数据库中不会明文保存密码。

总结一下，获取器是“读时转换”，修改器是“写时转换”。它们共同构成了Laravel模型属性处理的强大工具集，帮助开发者在数据进出数据库时保持一致性和业务逻辑的封装。选择哪一个取决于你的需求是处理数据展示，还是处理数据存储。

如何让模型获取器自动包含在JSON或数组输出中？

在构建API或需要将模型实例转换为JSON或数组格式时，一个常见需求是希望自定义的获取器也能被自动包含进去。默认情况下，当你调用

$model->toArray()

登录后复制

或

$model->toJson()

登录后复制

方法时，只有那些对应数据库列的属性才会被包含。但Laravel提供了一个非常简洁的方式来解决这个问题，那就是使用模型中的

$appends

登录后复制

属性。

$appends

登录后复制

属性是一个数组，你可以在其中列出所有你希望在模型转换为数组或JSON时自动附加的获取器名称。这些名称应该与你定义的获取器方法名中的“属性名”部分一致，也就是

get{AttributeName}Attribute

登录后复制

中的

{AttributeName}

登录后复制

的小写蛇形命名。

豆绘AI

豆绘AI是国内领先的AI绘图与设计平台，支持照片、设计、绘画的一键生成。

485

查看详情

举个例子，继续使用我们之前的

User

登录后复制

模型，它定义了

full_name

登录后复制

和

is_admin

登录后复制

获取器：

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class User extends Model
{
    // ... 其他属性和方法 ...

    /**
     * 声明哪些获取器应该在模型转换为数组或 JSON 时自动附加。
     *
     * @var array
     */
    protected $appends = ['full_name', 'is_admin'];

    /**
     * 获取用户的全名。
     *
     * @return string
     */
    public function getFullNameAttribute()
    {
        return "{$this->first_name} {$this->last_name}";
    }

    /**
     * 获取用户是否是管理员。
     *
     * @return bool
     */
    public function getIsAdminAttribute()
    {
        return (bool) $this->is_admin; // 假设 is_admin 是数据库字段
    }
}

登录后复制

现在，当你获取一个

User

登录后复制

模型实例并将其转换为数组或JSON时，

full_name

登录后复制

和

is_admin

登录后复制

这两个获取器的值就会自动包含在输出中：

$user = User::find(1);

// 转换为数组
$userData = $user->toArray();
/*
$userData 会类似这样：
[
    'id' => 1,
    'first_name' => 'John',
    'last_name' => 'Doe',
    'email' => 'john.doe@example.com',
    'full_name' => 'John Doe', // 自动包含了！
    'is_admin' => true,        // 自动包含了！
    // ... 其他数据库字段
]
*/

// 转换为 JSON 字符串
$userJson = $user->toJson();
// 同样，JSON 字符串中也会包含 full_name 和 is_admin 字段

登录后复制

需要注意的是，

$appends

登录后复制

属性中的名称必须与获取器方法名中的属性部分（小写蛇形）严格对应。如果你的获取器执行了复杂的计算或数据库查询，将其添加到

$appends

登录后复制

可能会在大量模型实例被序列化时引入性能问题（例如，N+1 查询）。在这种情况下，你可能需要仔细权衡，或者只在特定需要时手动附加这些属性，而不是全局使用

$appends

登录后复制

。

定义获取器时有哪些常见的陷阱或最佳实践？

虽然Laravel获取器非常强大且方便，但在实际使用中，如果不注意一些细节，也可能会遇到一些问题或导致代码质量下降。以下是一些常见的陷阱和推荐的最佳实践：

常见陷阱：

在获取器中执行数据库查询 (N+1问题): 这是最常见的性能陷阱。如果你的获取器内部执行了新的数据库查询来获取相关数据，并且这个模型实例被批量加载（例如，
```
User::all()
```
登录后复制
），那么每次访问这个获取器都会触发一次额外的查询。这会导致臭名昭1的N+1问题，严重拖慢应用速度。
- 示例：
```
getUserOrdersCountAttribute()
```
  登录后复制
  在其中
```
return $this->orders()->count();
```
  登录后复制
- 后果： 如果加载100个用户，就会有101次数据库查询（1次加载用户，100次加载订单数量）。
获取器逻辑过于复杂或执行耗时操作: 获取器应该尽量保持轻量和快速。如果你的获取器需要进行大量计算、外部API调用或复杂的数据处理，那么它可能会阻塞请求，影响用户体验。
- 示例： 在获取器中调用第三方服务，或者进行复杂的图像处理。
命名冲突: 确保你的获取器名称（
```
{AttributeName}
```
登录后复制
部分）不会与模型中已有的数据库字段名、关系方法名或模型自带的魔术方法名冲突。否则，可能会导致意料之外的行为。
过度使用
```
$appends
```
登录后复制
: 尽管
```
$appends
```
登录后复制
很方便，但如果你将所有获取器都添加到
```
$appends
```
登录后复制
中，即使在不需要这些数据的情况下，它们也会被计算并包含在JSON/数组输出中。这可能会增加不必要的处理开销和数据传输量，尤其是在大型数据集中。

最佳实践：

保持获取器简洁和专注: 获取器最适合用于数据的格式化、简单的派生值计算或布尔类型转换。如果逻辑变得复杂，考虑将其提取到模型中的私有方法、专用的服务类或观察者中。
利用 Eager Loading (预加载) 解决 N+1 问题: 如果获取器需要依赖关联数据，请确保在使用模型时通过
```
with()
```
登录后复制
方法进行预加载。这样，所有相关数据都会在一次查询中加载，避免了获取器内部的重复查询。
- 示例：
```
User::with('orders')->get();
```
  登录后复制
  然后在
```
getUserOrdersCountAttribute()
```
  登录后复制
  中直接访问已加载的
```
orders
```
  登录后复制
  关系。

缓存昂贵的计算结果: 对于那些计算成本较高但结果不经常变化的获取器，考虑在模型实例的生命周期内缓存其结果。

示例：

public function getComplexCalculationResultAttribute()
{
    if (! isset($this->attributes['cached_complex_result'])) {
        // 执行耗时计算
        $result = $this->performHeavyCalculation();
        $this->attributes['cached_complex_result'] = $result;
    }
    return $this->attributes['cached_complex_result'];
}

登录后复制

当然，更完善的缓存策略可能涉及 Laravel 的缓存系统。

区分展示逻辑与业务逻辑: 获取器主要用于展示层的数据准备。核心业务逻辑或会改变模型状态的操作不应该放在获取器中。这些应该放在模型方法、服务或控制器中。
合理使用
```
$appends
```
登录后复制
: 只有那些在绝大多数API响应或数据传输中都需要的获取器才应该添加到
```
$appends
```
登录后复制
。对于不常用的获取器，可以在需要时手动访问，或者在控制器中根据需要选择性地附加。