Laravel中“懒加载”是性能陷阱，须禁用并强制预加载；开发时启用Model::preventLazyLoading()，生产环境N+1会静默拖垮接口；with()必须在get()前调用且关系名严格匹配，事务中避免with()和循环load()，访问器内禁止数据库查询。
直接结论：Laravel 中的“懒加载”不是功能，而是性能陷阱；避免它的唯一可靠方式是——不用它。 开发阶段开启 Model::preventLazyLoading()，强制所有关联访问必须显式预加载，否则报错。生产环境不会报错，但 N+1 会静默拖垮接口。
with() 必须写在 get() 前，且关系名要完全匹配
写了 with('posts') 却仍看到几十条 SELECT * FROM posts WHERE user_id = ?，说明预加载根本没生效。常见原因：
- 模型里没有叫
posts()的方法（不能是getPostsAttribute()或userPosts()） - 外键不是默认的
user_id，但没在关系方法里显式声明，比如：$this->hasMany(Post::class, 'author_id') - 嵌套写法如
with('posts.comments')要求Post模型里也存在comments()方法，缺一个就断链 - Blade 模板里写了
{{ $user->posts->first()->title }}，但控制器没调with('posts')—— 这就是懒加载触发点
事务里别碰 with()，更别在循环里调 load()
在 DB::transaction() 块里写 User::with('profile')->get()，可能因隔离级别导致查询阻塞或锁竞争。正确做法是：
- 事务前查好数据：
$users = User::with('profile')->get(); - 事务内只操作已加载的实例，用
$user->relationLoaded('profile')确认，避免误触$user->profile - 如果必须在事务中补查，用
$users->load('profile')批量加载，绝不要 在 foreach 里对每个$user单独调$user->load('profile')—— 那又变回 N+1
访问器（accessor）里藏查询，等于给 N+1 加速器
像 getCalculationAttribute() 这类方法，如果内部写了 $this->scores->pluck('score_id') 或 Score::whereIn(...)->get()，那在 Blade 循环里每访问一次，就多几条 SQL。这不是懒加载“没关好”，而是设计上就绕过了 Eloquent 的预加载机制。
- 先确保主查询已
with('scores')，让$this->scores返回内存集合，而非触发新查询 - 访问器里禁止再查数据库；复杂计算逻辑应提前在控制器或查询构造阶段完成
- 若必须动态聚合，改用
withCount()、withSum()或selectRaw()在主查询中一并算好
真正难的不是写出一句正确的 with()，而是在模型定义、访问器、事务边界和模板渲染之间，保持关联加载意图的一致性。任何一处松动，N+1 就会从缝隙里钻出来，而且往往只在高并发时才暴露。
