Laravel模型内存占用差异原因及第二种优化方案风险咨询

问题背景 #

我在Laravel中发现两种实例化Video模型的方式存在明显内存占用差异，现解析原因并评估第二种方案的风险。

Video模型代码 #

class Video extends Model
{
    use HasFactory;

    public $timestamps = false;

    protected $fillable = [
        'article_id',
        'url',
        'source',
    ];
}

案例1：通过Eloquent查询实例化 #

$memoryStart = memory_get_usage();

$videoModel = Video::first();

$memory = memory_get_usage() - $memoryStart;
$this->info(round($memory / 1024 / 1024, 2));

内存占用结果：1.9 MB

案例2：通过DB查询后手动实例化 #

$memoryStart = memory_get_usage();

$videoAttributes = DB::table('videos')->first();
$videoModel = new Video((array)$videoAttributes);

$memory = memory_get_usage() - $memoryStart;
$this->info(round($memory / 1024 / 1024, 2));

内存占用结果：1.11 MB

内存差异的原因 #

• Eloquent查询的额外开销：Video::first()是通过Eloquent ORM执行查询，除了返回模型实例，还会加载一系列ORM核心组件：
  • 完整的查询构建器实例，包含查询条件、连接信息、查询日志等元数据；
  • 模型事件系统的初始化结构（即使未自定义事件，框架也会默认加载相关监听逻辑）；
  • 属性追踪机制，比如$original、$changes数组，用于记录属性变更，支持后续的save()、update()操作；
  • 关联关系管理器容器（即便模型没有定义关联，ORM也会初始化空的关联管理实例）。
• 手动实例化的轻量化：DB::table()->first()返回的是标准StdClass对象，转数组后传入模型构造器，只会完成基础属性的填充，不会触发Eloquent查询流程中的额外组件加载，也不会初始化属性追踪、关联管理器等ORM特性，因此内存占用更低。

第二种方案的风险 #

• 丢失ORM核心功能：手动实例化的模型没有Eloquent的属性追踪能力，调用save()、update()时无法自动识别变更字段，会执行全字段更新；同时isDirty()、getOriginal()等属性检查方法也无法正常工作。
• 关联关系失效：模型的关联方法（如hasOne、belongsTo）虽然存在，但关联管理器未正确初始化，调用关联方法时可能抛出异常或无法正确加载关联数据。
• 模型事件不触发：Eloquent的creating、created等模型事件不会被触发，依赖这些事件的业务逻辑（如数据校验、日志记录）会直接失效。
• 数据填充风险：DB::table()->first()返回的对象转数组时，若存在与模型$fillable不匹配的字段，可能绕过填充限制直接赋值给模型，导致非预期的属性被填充。
• 缺乏查询优化机制：Eloquent自带的查询缓存、查询复用机制无法生效，批量操作时无法复用查询构建器实例，可能带来额外的性能损耗。

内容的提问来源于stack exchange，提问作者Vlad