Eloquent Attribute Internal Transitions 并非 Laravel 官方术语，实指模型属性读写时的自动转换逻辑，主要包括 casts（基础类型转换）和访问器/修改器（业务级格式化），状态变更则应通过显式方法或事件处理。
什么是 Eloquent Attribute Internal Transitions？
这个词不是 Laravel 官方术语，也没有 AttributeInternalTransitions 这个类或方法。它大概率是有人把「模型属性访问时的内部状态转换」（比如 getter/setter 中对值做格式化、类型转换、状态映射）和「状态机（state machine）」概念混在一起后自造的说法。
实际开发中，你遇到的所谓“内部转换”，基本就两类：一是访问器/修改器（getFooAttribute/setFooAttribute），二是模型事件或 casts 配置触发的隐式转换。别被名字吓住，核心就是「读写字段时自动加工」。
用 casts 处理基础类型转换最省心
casts 是最常用也最安全的方式，适合布尔、日期、JSON、数组等标准类型。Laravel 在取值（$model->foo）和设值（$model->foo = ...）时自动调用底层转换逻辑，不侵入业务逻辑。
常见踩坑点：
立即学习“PHP免费学习笔记（深入）”；
-
casts对null值默认不处理，比如'active' => 'boolean'，当数据库存的是NULL，取出来会是false而非null—— 如果业务需要区分「未设置」和「否」，就得改用访问器 -
date或datetimecast 依赖Carbon，但不会自动处理时区；若数据库字段是INT时间戳，casts不生效，得手写访问器 - 自定义 cast 类必须实现
Castable接口，并提供serialize/unserialize方法，否则保存时可能出错
示例：protected $casts = ['is_published' => 'boolean', 'meta' => 'array'];
用访问器/修改器（Accessors/Mutators）做业务逻辑级转换
当你需要根据其他字段判断、调用服务、查库、或做非标准格式转换（如把 status 码转成中文描述），就必须用访问器/修改器。命名必须严格为 getFooAttribute / setFooAttribute，且 Foo 是 PascalCase 的属性名（对应数据库字段 foo）。
关键细节：
- 访问器里不能直接调用
$this->foo，否则会无限递归 —— 应该用$this->attributes['foo']或parent::getAttribute('foo') - 修改器接收原始输入值（比如前端传来的字符串
"1"），你要自己校验、转换，再赋给$this->attributes['foo'] - 如果同时定义了
casts和访问器，casts会先执行，访问器拿到的是已转换后的值 —— 这点常被忽略，导致重复转换
示例：把整数 status 映射为中文标签：
public function getStatusLabelAttribute()
{
$map = [0 => '草稿', 1 => '已发布', 2 => '已下线'];
return $map[$this->attributes['status']] ?? '未知';
}
状态变更逻辑别塞进访问器，用模型事件或显式方法
如果你说的“内部转换”其实是指「状态流转」（如 order 从 pending → paid → shipped），那绝对不要在访问器里触发状态变更、发通知、扣库存。访问器是纯读操作，不该有副作用。
正确做法：
- 把状态变更封装成模型方法，比如
public function markAsPaid()，里面做校验、更新字段、触发事件 - 用
static::updating()或saved事件监听变更，但注意事件里再改模型属性可能引发二次保存，需加 guard - 复杂状态机建议用独立包（如
spatie/laravel-model-states），它把状态定义、转换规则、钩子都收拢管理，比手写 if-else 清晰得多
一个典型错误：getIsPaidAttribute 里偷偷调用 $this->update(['status' => 'paid']) —— 下次读这个属性又会再触发，根本停不下来。
真正难的不是写转换逻辑，而是分清「数据呈现转换」和「业务状态变更」的边界。前者用 casts 或访问器，后者必须走显式方法或事件。混淆这两者，轻则数据不一致，重则无限循环或静默失败。
