预加载通过with()或load()方法解决N+1查询问题，减少数据库查询次数，提升性能。例如查询20篇文章及作者时，未预加载需21次查询，而使用with('user')仅需2次。还可通过withCount()统计关联数量、loadMissing()避免重复加载、$with属性设置默认预加载，但需警惕过度预加载导致内存溢出，应按需加载并结合实际场景优化。
Laravel模型关联预加载，简单来说，就是一种优化数据库查询的策略，它能有效解决我们常说的N+1查询问题，通过在执行主查询时一并加载相关联的数据，而不是在需要时才逐条去查询，从而显著提升应用的性能。实现预加载的核心方法主要就是使用
with()或
load()。
解决方案
我们在开发基于Laravel的应用时，经常会遇到一个经典的性能陷阱——N+1查询问题。想象一下，你有一个
Post模型，每个
Post都属于一个
User。当你查询20篇文章，然后遍历它们并显示每篇文章的作者名字时，如果不做任何处理，Laravel会先执行一条查询获取20篇文章，然后为每一篇文章再单独执行一条查询去获取其作者信息，这样一来，总共就会有1（文章）+ 20（作者）= 21条数据库查询。这显然是低效的。
预加载就是为了解决这个问题。它通过一次或少数几次查询，就将所有需要的数据（包括关联数据）从数据库中取出来。
最直接的实现方式就是使用
with()方法。
// 假设我们想获取所有文章及其作者
$posts = App\Models\Post::with('user')->get();
foreach ($posts as $post) {
echo $post->title . ' by ' . $post->user->name;
}这段代码，
with('user')告诉Laravel，在查询posts的时候，也一并把它们关联的
User数据加载进来。这样，无论有多少篇文章，Laravel都只会执行两条查询：一条获取所有文章，另一条获取所有相关联的用户。
如果你的模型实例或集合已经存在，你也可以使用
load()方法来预加载：
$posts = App\Models\Post::all(); // 此时N+1问题已存在
// 可以在现有集合上加载关联关系
$posts->load('user');
foreach ($posts as $post) {
echo $post->title . ' by ' . $post->user->name;
}这对于你已经获取了一部分数据，但后续需要用到其关联关系，又不想重新查询整个集合时非常有用。
对于更复杂的场景，比如多层嵌套的关联，
with()也能很好地处理：
// 假设Post有一个User，User有一个Profile
$posts = App\Models\Post::with('user.profile')->get();
foreach ($posts as $post) {
echo $post->title . ' by ' . $post->user->name . ' (' . $post->user->profile->bio . ')';
}这样会执行三条查询：文章、用户、用户档案。
有时候我们还需要对预加载的关联关系添加额外的约束，比如只加载活跃的作者：
$posts = App\Models\Post::with(['user' => function ($query) {
$query->where('status', 'active');
}])->get();这样，只有状态为
active的用户才会被预加载进来。
为什么我们总要提Laravel的N+1查询问题？它到底有多“致命”？
说实话，N+1查询问题在Laravel（乃至任何ORM框架）中，几乎是我在代码审查时最常指出的性能隐患之一。它之所以“致命”，并非总是一开始就让你的应用崩溃，而是像温水煮青蛙一样，在不经意间蚕食着应用的性能和用户体验。
它的核心问题在于，当你需要获取一个主模型集合及其关联模型时，如果没有预加载，系统会先执行一次查询获取主模型集合（N=1），然后对于集合中的每一个主模型实例，再单独执行一次查询去获取其关联模型。如果主模型集合中有M个实例，那么总共就会是1 + M次查询。
举个例子，假设我们有一个电商网站，要展示100个订单，每个订单都有一个对应的顾客信息：
一套面向小企业用户的企业网站程序！功能简单，操作简单。实现了小企业网站的很多实用的功能，如文章新闻模块、图片展示、产品列表以及小型的下载功能，还同时增加了邮件订阅等相应模块。公告，友情链接等这些通用功能本程序也同样都集成了！同时本程序引入了模块功能，只要在系统默认模板上创建模块，可以在任何一个语言环境（或任意风格）的适当位置进行使用！
// 未使用预加载
$orders = App\Models\Order::all(); // SELECT * FROM orders; (1次查询)
foreach ($orders as $order) {
echo "订单号: " . $order->id . ", 顾客: " . $order->customer->name;
// 每次访问 $order->customer 都会触发一次 SELECT * FROM customers WHERE id = ?;
// 如果有100个订单，这里会执行100次查询
}
// 总共：1 + 100 = 101次数据库查询这101次查询，意味着什么？
- 数据库连接开销： 每次查询都需要建立、维护、关闭数据库连接（或从连接池获取），这本身就是资源消耗。
- 网络延迟： 每次查询请求都要通过网络发送到数据库服务器，再等待结果返回。如果你的应用服务器和数据库服务器不在同一台机器上，或者网络状况不佳，这累积起来的延迟是相当可观的。100次小的网络往返，可能比1次大的往返耗时更多。
- 数据库服务器负载： 频繁的小查询会给数据库服务器带来不必要的压力，尤其是当并发用户量大时，可能会导致数据库连接池耗尽、CPU飙升，甚至服务崩溃。
- 内存与CPU： 虽然单次查询的数据量可能不大，但频繁地执行查询、解析结果集，也会占用应用服务器的CPU和内存资源。
N+1问题最“狡猾”的地方在于，它在开发初期，数据量小的时候，可能根本不显眼。你可能只有几条数据，1+5次查询和1+1次查询看起来没太大区别。但一旦数据量增长到几十、几百、几千，甚至上万，这个性能瓶颈就会突然变得非常突出，让你的页面加载时间从几十毫秒飙升到几秒甚至几十秒。我见过不少项目，上线后因为N+1问题导致页面响应慢如蜗牛，最后不得不紧急回溯代码进行优化。所以，在开发阶段就养成预加载的好习惯，是避免未来踩坑的有效手段。
除了with()
和load()
，还有哪些“花式”预加载技巧能让代码更优雅高效？
除了最常用的
with()和
load()，Laravel还提供了一些非常有意思的“花式”预加载技巧，它们能让你的代码在特定场景下更优雅、更高效，避免写一些冗余的逻辑，或者说，让ORM层能帮你做更多事情。
-
聚合函数预加载：
withCount()
,withExists()
,withAvg()
,withSum()
等 有时候我们并不需要完整的关联模型数据，而只是想知道关联模型的数量、是否存在，或者某个字段的平均值、总和。这时候，withCount()
系列方法就派上用场了。// 获取所有文章，并直接在每个文章对象上附加评论数量 $posts = App\Models\Post::withCount('comments')->get(); foreach ($posts as $post) { echo $post->title . ' 有 ' . $post->comments_count . ' 条评论。'; } // 还可以计算平均分 $products = App\Models\Product::withAvg('reviews', 'rating')->get(); foreach ($products as $product) { echo $product->name . ' 平均评分: ' . $product->reviews_avg_rating; }这比先预加载所有评论，再手动
count()
要高效得多，因为它直接在数据库层面进行聚合计算。 -
延迟预加载（Lazy Eager Loading）：
loadMissing()
loadMissing()
是一个非常实用的方法，它只会在关联关系尚未加载时才执行预加载。这在某些情况下，比如你可能已经通过其他方式加载了部分关联，或者想避免重复加载时非常有用。$user = App\Models\User::find(1); // 假设 user->posts 已经被某些操作加载过了 // 只有当 posts 关联尚未加载时，才会执行查询 $user->loadMissing('posts'); -
模型默认预加载：
$with
属性 如果你知道某个模型在几乎所有情况下都需要预加载某个关联关系，你可以直接在模型类中定义$with
属性。// App/Models/Post.php class Post extends Model { protected $with = ['user']; // 每次查询Post时，都会自动预加载User // ... } // 现在，无论你如何查询Post，User都会被自动加载 $posts = App\Models\Post::all(); // 已经包含了User数据这非常方便，但也要注意，它会增加所有
Post
查询的开销，即使在某些场景下你并不需要User
数据。所以，使用时要权衡利弊。 -
条件式预加载（Conditional Eager Loading） 有时候，我们只在满足特定条件时才需要预加载某个关联。虽然
with()
闭包可以实现，但whenLoaded()
方法在模型实例上也能提供类似的便利。$posts = App\Models\Post::all(); // 假设我们只在特定条件下才需要加载评论 if (some_condition_is_true()) { $posts->load('comments'); }这更像是手动控制，但逻辑清晰。
-
通过全局作用域（Global Scopes）实现预加载 虽然不直接是预加载方法，但全局作用域可以用来确保某个关联总是被加载，或者在加载时应用特定约束。这与
$with
属性类似，但更灵活，可以定义更复杂的逻辑。// 定义一个作用域，确保每次查询User时都预加载Profile // App/Models/User.php protected static function booted() { static::addGlobalScope('withProfile', function (Builder $builder) { $builder->with('profile'); }); }这样，每次
User::all()
都会自动带上profile
。如果需要绕过，可以使用User::withoutGlobalScope('withProfile')->get()。
这些技巧各有侧重，选择哪种方式取决于具体的业务需求和对性能的考量。在我看来，灵活运用它们，能够让你的Laravel应用在数据访问层面更加精细和高效。
预加载是不是“万金油”？什么时候不应该使用，或者说，使用时需要注意什么？
预加载无疑是解决N+1查询问题的利器，但它绝非“万金油”，也不是越多越好。在我看来，任何优化手段都有其适用场景和潜在的副作用。不恰当的预加载，反而可能带来新的性能问题，甚至比N+1问题更难察觉。
什么时候不应该使用预加载，或需要特别注意：
-
过度预加载（Over-eager Loading）导致内存爆炸： 这是预加载最常见的陷阱之一。如果你一股脑地预加载了所有可能的关联关系，而这些关系在当前请求中大部分都不会被用到，那么你就是在浪费资源。 例如，你查询了1000篇文章，每篇文章都预加载了
User
、comments
、tags
、categories
、attachments
等十几个关联。如果comments
和attachments
每个都有几十条数据，那么1000篇文章可能会加载几十万条关联数据到内存中。这会导致：- 内存占用飙升： PHP进程的内存消耗会急剧增加，可能导致内存溢出（Out Of Memory）。
- 数据传输量大： 即使数据库查询次数减少了，但单次查询传输的数据量会变得非常巨大，同样会增加网络延迟和数据库负载。
- CPU开销： Laravel在将这些原始数据映射到模型实例时，也会消耗CPU资源。
我的建议是： 永远只预加载你当前页面或当前逻辑中确实需要的关联关系。如果某个关联只有在用户点击某个按钮后才需要，那么就考虑懒加载（
$post->load('comments')）或者通过API异步加载。 -
关联数据量极大时： 如果某个关联关系的数据量非常庞大，比如一个用户可能有几万条日志记录，那么预加载
user->logs
可能会带来灾难性的后果。在这种情况下，更好的做法是：-
分页加载： 只加载部分关联数据，例如
$user->logs()->paginate(10)
。 -
使用聚合函数： 如果只需要统计数量，使用
withCount()
而不是加载所有数据。 - 重新思考数据结构： 某些“一对多”关系在实际应用中可能更像“一对无限多”，此时可能需要考虑将部分数据独立存储或设计更高效的查询方案。
-
分页加载： 只加载部分关联数据，例如
复杂查询与多重
JOIN
的替代方案： 虽然预加载在很多情况下能避免N+1，但如果你的业务逻辑需要非常复杂的过滤、排序，并且涉及多个关联模型的字段，有时直接使用JOIN
语句，或者通过DB::table()
构建查询，甚至编写原始SQL，可能会比ORM的预加载更高效、更灵活。ORM在处理极度复杂的交叉查询时，生成的SQL可能不是最优的。$with
属性的滥用： 在模型中使用protected $with = ['relation'];
固然方便，但它意味着每次查询该模型时，都会无条件地加载这些关联。如果你的模型在很多场景下并不需要这些关联，那么这就会变成一种“过度预加载”。我个人倾向于在需要时显式调用with()
，或者只对那些几乎总是需要的、且数据量不大的关联使用$with
。
总结来说，预加载的精髓在于“按需加载”和“适度加载”。 它是一个性能优化的工具，但不是一个可以无脑使用的“开关”。在使用预加载时，我们应该始终保持一种审慎的态度，结合实际的业务场景、数据量和性能监控数据来做决策。一个好的实践是，在开发过程中就多留意SQL日志，看看Laravel实际执行了多少条查询，以及这些查询的耗时，这样才能更准确地判断预加载是否带来了真正的价值。
