Eloquent 的 $casts 和 getAttribute() 会拖慢查询，因模型实例化后对每个 $casts 字段和自定义访问器均强制运行时计算，且 toArray()/JSON 转换时无差别执行所有访问器，包括含 DB 查询、HTTP 调用等重操作。
为什么 Eloquent 的 $casts 和 getAttribute() 会拖慢查询
因为 Laravel 在模型实例化后，对每个 $casts 字段和自定义访问器（如 getCreatedAtAttribute()）都会触发运行时计算，哪怕你根本没用到这个属性。更隐蔽的是：只要模型被转成数组或 JSON（比如 API 返回），所有访问器都会无差别执行——包括那些做了 DB 查询、文件读取、HTTP 调用的“重”访问器。
实操建议：
- 检查模型中是否在
getXXXAttribute()里写了DB::table()->where()->first()这类操作，这是性能杀手 - 用
toArray()前先调用unset($model->appends)或显式指定makeHidden(['heavy_attr']) - 把真正需要动态计算的字段移出访问器，改用服务类按需调用，比如
UserProfileService::formattedName($user)
如何避免 append() 自动触发所有访问器
append() 不是“懒加载”，而是强制把对应访问器结果塞进数组输出——哪怕该字段只在某个特定接口里需要，也会在所有 toArray() 场景下执行。尤其当多个模型互相 append() 形成链式调用时，很容易引发 N+1 访问器问题。
实操建议：
- 不要在模型里全局写
protected $appends = ['full_name']，改用局部追加：$user->append(['full_name'])->toArray() - 对高频接口（如列表页），直接在
select()里用原生 SQL 计算字段，比如selectRaw("CONCAT(first_name, ' ', last_name) as full_name") - 如果必须用访问器，加缓存层：
return $this->attributes['full_name'] ??= $this->computeFullName();
cast 属性在大批量数据场景下的内存陷阱
当你用 $casts = ['meta' => 'array'] 处理 JSON 字段时，Laravel 会在每次获取 $model->meta 时调用 json_decode()。如果一次查 1000 条记录，每条 meta 是 50KB 的 JSON，就会额外触发 1000 次解码 + 分配内存，极易 OOM。
实操建议：
- 大字段（如日志、配置、富文本）别走
$casts，改用getAttributeValue('meta')手动控制解码时机 - 用
asArray()替代toArray()可跳过 cast 转换（需 Laravel 10.29+） - 对只读场景，考虑在数据库层用生成列（generated column）预计算，比如 MySQL 的
AS (JSON_EXTRACT(meta, '$.status')) STORED
用 $withAttributes 避免访问器污染原始数据
有些字段你既想保留原始值（比如存的是时间戳整数），又想提供格式化版本（created_at_formatted）。如果全靠访问器，$model->created_at 就不再是原始值，后续做时间比较、序列化、队列传递都会出错。
实操建议：
- 原始字段保持原样，格式化字段用独立方法：
public function getCreatedAtFormattedAttribute() { return date('Y-m-d', $this->created_at); } - 在 API 资源类（
Resource）里做最终组装，而不是在模型里混用原始与衍生数据 - 必要时用
$model->getRawOriginal('created_at')确保拿到未 cast、未访问器处理的底层值
真正卡顿的地方往往不在 SQL，而在模型层对每个字段的“过度体贴”。Eloquent 的便利性是有代价的——它默认为你做所有事，但你要清楚哪些事其实不该让它做。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
