eloquent attribute states是用访问器、修改器和类型转换封装模型字段语义的轻量模式，仅抽象魔法值，不提供状态流转校验；而状态机（如spatie/laravel-model-states）具备状态图、过渡规则、历史审计等完整能力。
什么是Eloquent Attribute States，它和状态机有啥区别？
不是 Laravel 官方功能，也不是 spatie/laravel-model-states 那种完整状态机。它指的是一种轻量级模式：把模型某个字段（比如 status）的取值范围、语义、转换逻辑，通过 Eloquent 的访问器（accessor）、修改器（mutator）和属性（$casts）封装起来，让业务代码里不直接写字符串或数字常量。
本质是「用属性抽象代替魔法值」，不是真正意义上的状态机（没有状态图、无过渡校验、不记录历史）。如果你需要强制状态流转、拒绝非法跳转、审计变更，得上 spatie/laravel-model-states 或自建状态机表。
怎么用 Accessor + Mutator 实现 status 字段的状态语义封装？
假设订单模型有个 status 字段存整数（1=待支付，2=已支付，3=已发货，4=已完成），你想让 $order->statusName 返回中文名，$order->status = 'paid' 自动转成 2。
实操建议：
- 在模型中定义常量映射：
public const STATUS_PENDING = 1;、public const STATUS_PAID = 2;等 - 加
statusName访问器，用match或数组查表返回可读名，避免 if-else 堆砌 - 加
status修改器，接收字符串（如'pending'）并转为对应整数；同时兼容传入数字，防止外部赋值崩掉 - 把
status加入$casts = ['status' => 'integer']，确保类型安全
示例片段：
protected $casts = [
'status' => 'integer',
];
protected function getStatusNameAttribute(): string
{
return match($this->status) {
self::STATUS_PENDING => '待支付',
self::STATUS_PAID => '已支付',
self::STATUS_SHIPPED => '已发货',
self::STATUS_COMPLETED => '已完成',
default => '未知',
};
}
protected function setStatusAttribute(string|int $value): void
{
$map = [
'pending' => self::STATUS_PENDING,
'paid' => self::STATUS_PAID,
'shipped' => self::STATUS_SHIPPED,
'completed' => self::STATUS_COMPLETED,
];
$this->attributes['status'] = is_string($value)
? ($map[$value] ?? self::STATUS_PENDING)
: (int) $value;
}
为什么不能只靠 $casts + 枚举类（PHP 8.1+）？
PHP 枚举（enum）确实能约束值范围，但 Eloquent 不原生支持枚举自动 cast 到数据库字段。你得手动写 from / to 方法，且无法在查询中直接用枚举实例做 where（比如 Order::where('status', OrderStatus::PAID) 会报错，因为底层还是存整数）。
常见错误现象：Call to a member function getValue() on null，往往是因为没在 mutator 里处理好枚举实例传入，或没重写 __toString()。
实操建议：
- 若坚持用枚举，必须配合自定义 cast 类（实现
CastsAttributes接口），把枚举实例 ↔ 整数双向转换 - 查询时仍需用
where('status', OrderStatus::PAID->value)，别漏掉->value - 枚举本身不能表达「允许从 A 转到 B」这类状态迁移规则，仅做值约束，别高估它的能力
什么时候该放弃 Attribute States，直接上 spatie/laravel-model-states？
当你遇到这些信号，说明已超出属性封装的边界：
- 产品需求明确要求「订单不能从‘已完成’退回到‘已支付’」，即需要运行时状态转移校验
- 要记录每次状态变更的时间、操作人、原因（得建单独的状态历史表）
- 不同角色对同一状态的操作权限不同（如客服能关单，用户不能）
- 状态值来源不止数据库字段，还可能来自第三方回调、定时任务、消息队列
这时硬靠 accessor/mutator 补丁式控制，代码会迅速腐化——校验散落在各处、历史难追溯、测试难覆盖。直接装 composer require spatie/laravel-model-states，用它的 State 类和 CanTransitionTo trait 更省心。
真正容易被忽略的是：状态语义和状态流转是两层事。Attribute States 只管第一层（“这个值代表什么”），第二层（“它能不能变成那个值”）必须另起炉灶，别混在一起硬撑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
