Laravel模型修改器通过获取器和修改器在数据读取和写入时自动处理数据。获取器用于格式化输出，如组合字段或转换类型；修改器用于预处理输入，如哈希密码或清洗数据。最佳实践包括保持逻辑简单、避免N+1查询，并合理使用$casts属性处理日期和JSON字段。常见陷阱有性能开销、调试困难及触发时机不符，需注意职责分离与数据流向。
Laravel修改器，或者我们常说的模型修改器，本质上就是Eloquent模型提供的一种机制，让我们能够在数据从数据库中读取出来（获取器，Accessor）或者写入数据库之前（修改器，Mutator）对数据进行自动化的转换或处理。它不是什么魔法，更像是一种约定俗成的钩子，让你能在数据流动的关键节点，插入自己的逻辑，让模型的数据表现得更符合你的预期，或者在存储时更安全、规范。
模型修改器的使用其实挺直观的，主要分为两种：获取器（Accessors）和修改器（Mutators）。
获取器（Accessors）
当你需要从数据库中取出某个属性，但希望它以某种特定格式或经过计算后的形式呈现时，获取器就派上用场了。比如，你想把用户的名字和姓氏组合成一个全名，或者把一个布尔值0/1转换成“是/否”的文本。
在你的Eloquent模型中，定义一个方法，命名规则是
get{AttributeName}Attribute{AttributeName}<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class User extends Model
{
/**
* 获取用户全名。
* 假设我们有 first_name 和 last_name 字段
*
* @param string $value 原始的属性值（如果存在同名属性，这里会是它）
* @return string
*/
public function getFullNameAttribute()
{
// 这里的 $this->first_name 和 $this->last_name 会自动从模型实例中获取
// 如果这两个字段不存在，那这里可能就得做一些空值检查了
return "{$this->first_name} {$this->last_name}";
}
/**
* 判断用户是否是管理员。
* 假设数据库中有一个 is_admin 字段，存储的是 0 或 1
*
* @param mixed $value is_admin 字段的原始值
* @return bool
*/
public function getIsAdminAttribute($value)
{
return (bool) $value;
}
}现在，你就可以像访问普通属性一样访问
$user->full_name
$user->is_admin
修改器（Mutators）
修改器则是在你给模型属性赋值时触发的。它允许你在数据保存到数据库之前，对其进行预处理。最常见的例子就是密码哈希，或者将用户输入的数据进行清洗、格式化。
定义修改器的方法命名规则是
set{AttributeName}Attribute<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Facades\Hash; // 用于密码哈希
class User extends Model
{
/**
* 在设置用户密码时自动进行哈希处理。
*
* @param string $value 用户输入的明文密码
* @return void
*/
public function setPasswordAttribute($value)
{
// 确保只有在密码非空时才进行哈希，避免空密码覆盖已哈希的密码
if (! empty($value)) {
$this->attributes['password'] = Hash::make($value);
}
}
/**
* 在设置电子邮件地址时，将其转换为小写并去除两端空白。
*
* @param string $value 用户输入的电子邮件地址
* @return void
*/
public function setEmailAttribute($value)
{
$this->attributes['email'] = strtolower(trim($value));
}
}当你像这样给模型赋值时：
$user->password = 'secret';
$user->email = ' TEST@EXAMPLE.COM ';
$this->attributes
需要注意的是，在修改器中，你必须通过
$this->attributes['attribute_name'] = $value;
$this->attribute_name = $value;
嗯，这其实是理解模型修改器核心的关键。获取器和修改器，虽然都叫“修改器”，但它们的作用方向是截然相反的。
获取器（Accessor）：它是在你从数据库“获取”数据后，但在你实际“使用”数据前，对数据进行一次转换。你可以把它想象成一个展示数据的“滤镜”或者“格式化器”。它的核心目的就是改变数据的表现形式，而不是数据本身。比如，数据库里存的是
'2023-10-27 10:30:00'
'October 27, 2023'
price
$19.99
修改器（Mutator）：这个则是在你把数据“存入”数据库前，对数据进行预处理。它关注的是数据的存储格式和安全性。比如，用户注册时输入了明文密码，我们肯定不能直接存明文，这时候修改器就负责把它哈希掉。又或者，用户输入的文本可能包含HTML标签，你希望在保存前进行XSS过滤，修改器也能胜任。它确保了存入数据库的数据是干净的、安全的，或者符合某种规范的。
最佳实践：
获取器：
getFormattedDateAttribute
getIsActiveAttribute
修改器：
$model->attribute = $value;
DB::table()->insert()
$fillable
$guarded
处理日期和JSON字段的自动转换，Laravel有更优雅、更推荐的方式，那就是模型的
$casts
$casts
日期字段的自动转换：
Laravel默认会把
created_at
updated_at
Carbon
published_at
Carbon
在过去，我们可能会在模型中定义
protected $dates = ['published_at'];
$casts
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
use Carbon\Carbon; // Carbon 是 Laravel 默认的日期处理库
class Post extends Model
{
protected $casts = [
'published_at' => 'datetime', // 将 published_at 字段自动转换为 Carbon 实例
'expires_at' => 'date', // 仅转换为日期部分，时间部分会被忽略
];
// ... 其他模型内容
}这样设置后，当你从数据库取出
$post->published_at
Carbon
$post->published_at->format('Y-m-d H:i:s')$post->published_at
DateTime
Carbon
JSON字段的自动转换：
对于需要存储JSON格式数据的字段（比如一个配置项、一个用户偏好设置），
$casts
Collection
<?php
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class User extends Model
{
protected $casts = [
'options' => 'array', // 将 options 字段自动转换为 PHP 数组
'settings' => 'json', // 效果同 'array'，但更明确表示是 JSON 存储
'preferences' => 'collection', // 转换为 Laravel 的 Collection 对象
];
// ... 其他模型内容
}现在，你可以直接像操作数组或
Collection
$user->options
$user->settings
$user->preferences
$user = User::find(1);
// 访问数组元素
echo $user->options['theme']; // 例如：'dark'
// 修改数组并保存
$user->options['notifications'] = true;
$user->save();
// 使用 Collection 方法
$user->preferences->each(function ($value, $key) {
// ...
});Laravel会自动处理序列化和反序列化，你无需手动调用
json_encode()
json_decode()
除了
DateTime
date
array
json
Collection
$casts
boolean
integer
real
float
double
string
虽然模型修改器和
$casts
1. N+1查询问题（尤其在获取器中）： 这是最常见也最容易被忽视的问题。如果你的获取器内部执行了额外的数据库查询，并且你在循环中访问这个获取器，那么就会产生N+1查询。 比如，你有一个
User
getLatestPostAttribute
// User 模型
public function getLatestPostAttribute()
{
return $this->posts()->latest()->first(); // 这里的查询会是问题所在
}
// 在控制器或视图中
$users = User::all(); // 1次查询
foreach ($users as $user) {
echo $user->latest_post->title; // N次查询，每次循环都查一次数据库
}这样，如果你有100个用户，就会发出101次数据库查询。解决方法通常是使用
with()
User::with('posts')->all();2. 性能开销： 如果获取器或修改器中包含复杂的计算、IO操作（比如文件读写），或者涉及大量数据的处理，那么每次模型加载或保存时都会执行这些操作，可能会导致性能下降，尤其是在处理大量模型实例时。例如，一个获取器要对一个长文本进行复杂的词频分析，如果每次访问都执行，那效率肯定不高。
3. 调试困难： 数据在进入模型和离开模型时都经过了转换，这有时会使调试变得复杂。当你看到一个奇怪的值时，你可能需要回溯，看看是获取器出了问题，还是修改器在保存前做了不该做的事，亦或是数据库里原始数据就是错的。
dd()
dump()
$this->attributes
4. 触发时机与预期不符： 修改器只在通过
$model->attribute = $value;
DB::table('users')->update(...)Model::create()
Model::update()
$fillable
$guarded
5. 命名冲突： 如果你有一个数据库字段名叫做
full_name
getFullNameAttribute
$model->full_name
$this->attributes['full_name']
6. 滥用与职责不清： 有时候，开发者会把过多的业务逻辑塞进获取器或修改器，导致模型变得“肥大”且职责不清。模型修改器应该专注于数据的转换和格式化，而不是复杂的业务决策。复杂的业务逻辑应该放在服务层、Repository层或专门的Action类中。一个好的原则是：如果一个转换逻辑只与数据的表示或存储格式有关，就放在这里；如果它涉及到多个模型的协作、外部服务调用或复杂的条件判断，那它可能就不属于这里了。
为了避免这些陷阱，关键在于理解其工作原理，并始终保持警惕。在开发过程中，多思考数据流向，预判可能出现的性能瓶颈，并在必要时进行性能测试。
以上就是Laravel修改器？模型修改器怎样使用？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
270
收藏
