Eloquent 的 getAttribute/setAttribute 不触发聚合逻辑，需用 accessor、Attribute 或数据库字段实现；status_summary 等未映射字段不可查、不可存、不序列化，须据业务明确其属视图计算还是核心状态。
Eloquent 的 getAttribute 和 setAttribute 不会自动触发聚合逻辑，必须显式定义访问器（accessor）或使用 $casts + 自定义 getter，否则状态聚合只是“看起来有”，实际查不到、存不进、改不了。
为什么直接在模型里写 public $status_summary 没用
PHP 属性声明是静态的，Eloquent 不会把未映射到数据库字段的 public 属性当作可序列化/可查询的属性。它既不会出现在 $model->toArray() 里，也不会响应 where() 或 orderBy()。
- 数据库中没有
status_summary字段 → 查询时无法where('status_summary', 'active') - 没定义 accessor →
$model->status_summary返回null或报错（取决于是否启用 strict mode） - 没定义 mutator → 即使手动赋值
$model->status_summary = 'xxx'，也永远不会持久化
用 Accessor 实现只读聚合状态（推荐场景：展示层汇总）
适合「计算得出、无需存储、仅用于 API 输出或 Blade 渲染」的聚合逻辑，比如订单当前状态 = 订单状态 + 支付状态 + 物流状态的组合判断。
在模型中添加：
立即学习“PHP免费学习笔记（深入）”；
protected $appends = ['status_summary'];
public function getStatusSummaryAttribute()
{
if ($this->status !== 'confirmed') {
return $this->status;
}
if ($this->payment_status === 'paid' && $this->shipping_status === 'shipped') {
return 'delivered';
}
if ($this->payment_status === 'paid') {
return 'ready_to_ship';
}
return 'pending_payment';
}
-
$appends是必需的，否则toArray()和 JSON 响应里不包含该字段 - 不要在 accessor 里调用
$this->save()或其他写操作，它只应在读取时执行 - 注意 N+1：如果批量查 100 个模型并访问
status_summary，且内部用了关联查询（如$this->orderItems），性能会崩
用 Attribute（Laravel 9+）替代 Accessor，更清晰控制读写行为
Laravel 9 引入的 Attribute 类让读写逻辑分离更明确，尤其适合「聚合状态需支持部分写入」的场景（例如允许前端 PATCH status_summary 触发多字段联动更新）。
示例：
use Illuminate\Database\Eloquent\Casts\Attribute;
protected function statusSummary(): Attribute
{
return Attribute::make(
get: fn () => match (true) {
$this->status === 'cancelled' => 'cancelled',
$this->payment_status === 'refunded' => 'refunded',
$this->payment_status === 'paid' && $this->shipping_status === 'delivered' => 'completed',
default => 'processing'
},
set: fn ($value) => $this->forceFill([
'status' => match ($value) {
'completed' => 'confirmed',
'cancelled' => 'cancelled',
default => 'draft'
},
'payment_status' => match ($value) {
'completed' => 'paid',
'cancelled' => 'refunded',
default => 'pending'
}
])
);
}
- getter 和 setter 完全解耦，语义比
getFooAttribute/setFooAttribute更紧凑 -
set回调里必须用forceFill()或fill()，不能直接赋值$this->status = ...，否则不会被 Eloquent 跟踪变更 - 不建议在
set里做复杂校验或 DB 查询——属性赋值应轻量，校验逻辑应放在updating事件或模型的save()前钩子中
聚合状态要进数据库？别硬塞，用观察者 + 状态机更稳
如果业务要求「status_summary 必须可索引、可搜索、可排序」，说明它已不是纯派生字段，而是领域核心状态之一。这时强行用 accessor 就是在绕开数据一致性。
- 在迁移中添加真实字段：
$table->string('status_summary')->index() - 用
Observing或booted()钩子，在关联字段变更时自动更新：static::updating(fn ($model) => $model->status_summary = $model->calculateStatusSummary()) - 关键点：所有可能影响聚合结果的字段（如
payment_status）更新时，都得触发重新计算——漏掉一个，状态就脱钩 - 更健壮的做法是引入
spatie/laravel-model-status或自建状态机，把「状态流转规则」显式编码，而不是靠散落在各处的 setter 或 observer
真正难的不是怎么写这个 accessor，而是想清楚：这个聚合状态到底属于「视图层临时计算」，还是「领域模型的核心契约」。前者用 accessor 或 Attribute 足够；后者必须落地为字段+约束+状态流转规则，否则上线后查三天 bug 才发现支付成功但订单还卡在 pending_payment，问题不在代码写法，而在状态归属没厘清。
