Laravel模型属性转换？属性类型如何转换？-Laravel-PHP中文网

Laravel模型通过$casts、访问器/修改器和自定义Cast类实现属性类型转换。$casts用于基础类型映射，如布尔、数组、日期等，读写时自动转换；访问器和修改器适用于复杂逻辑或虚拟属性，支持字段读取和赋值时的自定义处理；自定义Cast类则适合跨模型复用的复杂转换，如金额分与元的转换。底层由Eloquent的getAttributeFromArray和setAttribute方法驱动，结合Cast管理器调用对应类型处理器。优先使用$casts处理简单类型，访问器/修改器用于依赖多字段或特定模型的逻辑，自定义Cast类则提升复用性与可维护性。需注意数据类型匹配、NULL处理、时间格式、优先级冲突及性能问题，避免序列化时的额外开销。

laravel模型属性转换？属性类型如何转换？

Laravel模型属性的类型转换，核心上是通过Eloquent提供的几种机制来完成的，主要包括

$casts

登录后复制

属性、访问器（Accessors）和修改器（Mutators），以及更高级的自定义Cast类。这些方法各有侧重，能满足从最基础的类型映射到复杂业务逻辑处理的各种需求，让数据库原始数据在应用层面以更符合预期的PHP类型呈现。

解决方案

Laravel模型属性的类型转换可以通过以下几种主要方式实现，每种方式都有其适用场景和优势：

使用

$casts

登录后复制

属性： 这是最直接、最推荐的方案，用于将数据库列自动转换为常见的PHP数据类型。在你的模型中定义一个

$casts

登录后复制

数组，键是数据库列名，值是目标PHP类型。

class User extends Model
{
    protected $casts = [
        'is_admin' => 'boolean',      // 将 tinyint(1) 转换为布尔值
        'options' => 'array',         // 将 JSON 字符串转换为 PHP 数组
        'settings' => 'json',         // 另一种将 JSON 字符串转换为 PHP 数组/对象的方式
        'email_verified_at' => 'datetime', // 将时间戳或日期字符串转换为 Carbon 实例
        'price' => 'float',           // 将 decimal/string 转换为浮点数
        'meta_data' => 'collection',  // 将 JSON 字符串转换为 Laravel Collection
    ];
}

登录后复制

当从数据库读取

User

登录后复制

模型时，

is_admin

登录后复制

会自动是

true

登录后复制

或

false

登录后复制

，

options

登录后复制

和

settings

登录后复制

会是PHP数组，

email_verified_at

登录后复制

会是

Carbon

登录后复制

实例。反之，保存时也会自动转换回数据库兼容的格式。

使用访问器 (Accessors) 和修改器 (Mutators)： 当
```
$casts
```
登录后复制
无法满足需求，或者需要更复杂的读取/写入逻辑时，访问器和修改器提供了更大的灵活性。
- 访问器 (Getter)： 用于在从模型获取属性时对其进行转换。方法命名规则是
```
get{AttributeName}Attribute
```
  登录后复制
  。
- 修改器 (Setter)： 用于在设置模型属性时对其进行转换。方法命名规则是
```
set{AttributeName}Attribute
```
  登录后复制
  。
```
class User extends Model
{
    // 访问器：获取全名
    public function getFullNameAttribute()
    {
        return "{$this->first_name} {$this->last_name}";
    }

    // 修改器：保存时将名字首字母大写
    public function setFirstNameAttribute($value)
    {
        $this->attributes['first_name'] = ucfirst($value);
    }
}
```
登录后复制
这里
```
full_name
```
登录后复制
并不是数据库字段，而是通过访问器“虚拟”出来的一个属性。
```
first_name
```
登录后复制
在设置时会被自动处理。

使用自定义 Cast 类： 对于需要跨多个模型复用，或者逻辑非常复杂的类型转换，自定义 Cast 类是最佳选择。它允许你将转换逻辑封装在一个独立的类中。

首先，创建一个 Cast 类，实现

CastsAttributes

登录后复制

接口：

// app/Casts/MoneyCast.php
namespace App\Casts;

use Illuminate\Contracts\Database\Eloquent\CastsAttributes;
use Illuminate\Database\Eloquent\Model;

class MoneyCast implements CastsAttributes
{
    public function get(Model $model, string $key, mixed $value, array $attributes): mixed
    {
        // 从数据库读取时，将分（整数）转换为元（浮点数）
        return $value / 100;
    }

    public function set(Model $model, string $key, mixed $value, array $attributes): mixed
    {
        // 保存到数据库时，将元（浮点数）转换为分（整数）
        return (int) ($value * 100);
    }
}

登录后复制

然后在模型中使用它：

class Product extends Model
{
    protected $casts = [
        'price' => MoneyCast::class, // 使用自定义 Cast 类
    ];
}

登录后复制

这样，无论何时访问

Product

登录后复制

的

price

登录后复制

属性，它都会以元为单位的浮点数形式出现；保存时，则会自动转换为分存储。

Laravel模型如何自动进行类型转换？底层机制是什么？

Laravel模型实现自动类型转换，其核心在于Eloquent ORM的事件监听和属性处理机制。当我们谈论自动转换，通常是指通过

$casts

登录后复制

属性声明的那些。

简单来说，当Eloquent从数据库中取出一条记录，并将其实例化为模型对象时，它会检查该模型是否定义了

$casts

登录后复制

属性。如果定义了，Eloquent会遍历

$casts

登录后复制

数组，针对每个声明了转换的字段，调用相应的转换逻辑。例如，

'is_admin' => 'boolean'

登录后复制

，Eloquent会识别出这是一个布尔类型转换，然后将数据库中取出的

登录后复制

或

登录后复制

转换为PHP的

false

登录后复制

或

true

登录后复制

。对于

'datetime'

登录后复制

，它会将数据库的日期时间字符串（如

'2023-10-27 10:00:00'

登录后复制

）解析成一个

Carbon

登录后复制

实例，这大大方便了日期时间的处理。

机械轴承电子产品类网站源码

织梦最新内核开发的模板，518源码论坛亲自开发，转载请备注出处。该模板属于企业通用类、机械轴承、分条机类等设备类企业都可使用，这款模板使用范围极广，不仅仅局限于一类型的企业，你只需要把图片和产品内容换成你的，颜色都可以修改，改完让你耳目一新的感觉！自带最新的手机移动端，同一个后台，数据即时同步，简单适用！

145

查看详情

这个过程主要发生在

Illuminate\Database\Eloquent\Model

登录后复制

类的

getAttributeFromArray

登录后复制

和

setAttribute

登录后复制

方法中。

getAttributeFromArray

登录后复制

负责从原始数据库行数组中获取属性值并进行读取时的转换，而

setAttribute

登录后复制

则在设置属性时进行写入时的转换。

对于更深层次的理解，

$casts

登录后复制

实际上是利用了Laravel内部的“Cast管理器”。Laravel内置了一系列预定义的cast类型（如

int

登录后复制

float

登录后复制

boolean

登录后复制

string

登录后复制

array

登录后复制

json

登录后复制

object

登录后复制

collection

登录后复制

date

登录后复制

datetime

登录后复制

timestamp

登录后复制

等），每种类型都对应着一套处理逻辑。当你在

$casts

登录后复制

中指定一个类型时，Eloquent会查找并应用对应的处理逻辑。如果指定的是一个自定义Cast类，Eloquent就会实例化这个类，并调用其

get

登录后复制

和

set

登录后复制

方法来完成自定义的转换。

我个人觉得，这种设计非常优雅。它把数据存储层和应用逻辑层之间的“翻译”工作自动化了，避免了我们在每次使用某个字段时都手动去

json_decode()

登录后复制

或者

new Carbon()

登录后复制

。这不仅让代码更简洁，也减少了出错的可能性。而且，这种机制的侵入性很低，你只需要在模型中声明一下，剩下的就交给Eloquent了。

何时应该使用访问器和修改器，何时选择自定义Cast类？

这是一个很常见的选择困境，我在实际项目中也经常需要权衡。我的经验是，它们各有最适合的场景，理解这些场景能帮助你做出更好的决策。

访问器和修改器 (Accessors & Mutators) 的适用场景：

一次性或特定模型的复杂逻辑： 如果某个转换逻辑只适用于当前模型，或者逻辑本身比较复杂，不适合用简单的
```
$casts
```
登录后复制
表达，那么访问器和修改器是很好的选择。比如，根据用户的
```
first_name
```
登录后复制
和
```
last_name
```
登录后复制
动态生成一个
```
full_name
```
登录后复制
属性，或者在保存
```
password
```
登录后复制
时进行哈希加密。
依赖模型其他属性的转换： 有些转换需要用到模型中的其他属性。例如，一个
```
discounted_price
```
登录后复制
可能需要根据
```
original_price
```
登录后复制
和
```
discount_percentage
```
登录后复制
来计算。
副作用操作： 修改器可以包含一些副作用，比如在设置某个属性时触发一个事件，或者更新另一个相关属性。虽然不推荐滥用，但在某些特定业务场景下是有效的。
非数据库字段的“虚拟”属性： 访问器可以用来创建那些在数据库中并不存在，但逻辑上属于模型一部分的属性。比如一个
```
is_active
```
登录后复制
属性，它可能根据
```
status
```
登录后复制
字段和
```
expires_at
```
登录后复制
字段的组合来判断。

自定义Cast类的适用场景：

跨多个模型的复杂或重复逻辑： 这是自定义Cast类最核心的价值。如果你的转换逻辑在多个模型中都会用到（比如
```
MoneyCast
```
登录后复制
、
```
EncryptedStringCast
```
登录后复制
、
```
AddressCast
```
登录后复制
），那么将其封装成一个独立的Cast类，可以避免代码重复，提高可维护性。
需要独立测试的转换逻辑： 将转换逻辑封装在一个类中，使其更容易进行单元测试。你可以独立测试
```
MoneyCast
```
登录后复制
在
```
get
```
登录后复制
和
```
set
```
登录后复制
方法中的行为，而不需要依赖整个Eloquent模型。
更清晰的职责分离： 当转换逻辑变得复杂时，将其从模型中抽离出来，可以让模型本身更专注于业务逻辑，而不是数据格式的转换。
需要构造复杂对象： 如果你的数据库字段需要被转换成一个更复杂的PHP对象（例如一个值对象），自定义Cast类是理想选择。比如将一个JSON字符串转换为一个
```
Address
```
登录后复制
值对象，或者将一个整数转换为一个
```
Currency
```
登录后复制
对象。

总结一下我的看法： 当转换逻辑简单、普适，且不依赖其他字段时，

$casts

登录后复制

是首选。当转换逻辑复杂，或需要根据模型其他属性动态生成，且仅限于当前模型时，使用访问器和修改器。当转换逻辑复杂，且需要在多个模型中复用，或者需要将数据转换为一个独立的值对象时，自定义Cast类是最佳实践。它能让你的代码更DRY，更易于维护和测试。过度使用访问器和修改器可能会让模型变得臃肿，而自定义Cast则能有效解决这个问题。

Laravel模型属性转换有哪些常见陷阱和性能考量？

在模型属性转换上，虽然Laravel提供了极大的便利，但确实有一些常见的陷阱和值得注意的性能考量。我个人在项目中也踩过一些坑，所以分享一下经验。

常见陷阱：

数据类型不匹配导致的错误： 这是最常见的。如果你将一个可能包含非数字字符的数据库列
```
cast
```
登录后复制
为
```
int
```
登录后复制
或
```
float
```
登录后复制
，当遇到不规范的数据时，PHP会抛出类型转换错误或返回意外值。例如，数据库里某个
```
price
```
登录后复制
字段不小心存了
```
'N/A'
```
登录后复制
，你却
```
cast
```
登录后复制
成了
```
float
```
登录后复制
，那读取时就出问题了。
JSON/Array Cast的默认值问题： 当你将一个可空的JSON或数组字段
```
cast
```
登录后复制
为
```
array
```
登录后复制
或`
```
json
```
登录后复制
时，如果数据库中该字段为
```
NULL
```
登录后复制
，Laravel默认会将其转换为一个空数组
```
[]
```
登录后复制
。这通常是期望的行为，但如果你期望的是
```
NULL
```
登录后复制
，就需要特别处理，例如使用自定义Cast或者在访问器中判断。
时间戳与日期格式不一致：
```
$casts
```
登录后复制
中的
```
date
```
登录后复制
、
```
datetime
```
登录后复制
、
```
timestamp
```
登录后复制
会尝试将数据库值转换为
```
Carbon
```
登录后复制
实例。如果数据库中的日期时间格式不标准，或者与Laravel期望的格式不符，可能会导致解析失败。
```
created_at
```
登录后复制
和
```
updated_at
```
登录后复制
这些默认字段通常没问题，但自定义的日期字段需要注意。
访问器/修改器与
$casts
登录后复制
的优先级：当一个字段同时定义了
```
$casts
```
登录后复制
和一个访问器/修改器时，
```
$casts
```
登录后复制
的优先级更高。这意味着
```
$casts
```
登录后复制
会先执行，然后才是访问器/修改器。这通常不是问题，但如果你希望访问器/修改器在原始数据库值上操作，而不是
```
$casts
```
登录后复制
转换后的值，就需要注意了。
自定义Cast的
get
登录后复制
和
set
登录后复制
方法逻辑错误：在自定义Cast中，
```
get
```
登录后复制
和
```
set
```
登录后复制
方法必须是互逆的，即
```
set(get(value))
```
登录后复制
应该大致等于
```
value
```
登录后复制
。如果逻辑不严谨，可能导致数据在存取过程中丢失精度或发生不一致。

性能考量：

频繁的复杂转换： 对于大多数应用来说，模型属性转换的性能开销可以忽略不计。但如果你有一个高并发的应用，并且在每个请求中都要对成千上万个模型实例进行复杂的自定义Cast转换（例如，每个模型有几十个字段都需要通过自定义Cast进行复杂的计算），那么累积起来的开销就值得关注了。
数据库查询优化： 属性转换是在数据从数据库取出后在PHP层面进行的。这意味着，即使你将一个字段
```
cast
```
登录后复制
为
```
boolean
```
登录后复制
，在数据库查询时，你仍然应该使用数据库原生类型进行查询（例如
```
WHERE is_admin = 1
```
登录后复制
，而不是
```
WHERE is_admin = true
```
登录后复制
）。否则，可能会导致索引失效或全表扫描。
序列化开销： 当你将模型转换为数组或JSON（例如
```
$model->toArray()
```
登录后复制
或API响应）时，所有的访问器和
```
$casts
```
登录后复制
都会被执行。如果你的访问器或自定义Cast的
```
get
```
登录后复制
方法包含了大量的计算或数据库查询，那么在序列化大量模型时，可能会产生显著的性能瓶颈。我曾经遇到过一个访问器在每次调用时都执行额外数据库查询的场景，导致API响应时间急剧增加。
不必要的Cast： 并非所有数据库字段都需要
```
cast
```
登录后复制
。例如，一个
```
string
```
登录后复制
类型的字段，如果你在应用中也一直把它当作字符串使用，那么就没有必要
```
cast
```
登录后复制
为
```
string
```
登录后复制
。虽然这种开销很小，但避免不必要的转换总归是好的。