In Laravel, what does Model::preventLazyLoading() do, how should you enable it, and which lazy loads does it deliberately let through?

## What the switch does Eloquent lets you read a relation as a **dynamic property**, `$post->author`, and loads it on first access if nobody eager loaded it. That convenience is how N+1 query patterns reach production unnoticed. `Model::preventLazyLoading()` turns the silent query into an error during development: ```php use Illuminate\Database\Eloquent\Model; public function boot(): void { Model::preventLazyLoading(! $this->app->isProduction()); } ``` It is a **static, global** setting on the base `Model` class, so one call in `AppServiceProvider::boot()` covers every model. The skeleton's provider does not call it; strictness is opt-in. With it on, the next unloaded relation read as a property throws `Illuminate\Database\LazyLoadingViolationException`, whose message names the model and the relation, pointing straight at the missing `with()`. ## What it deliberately does not catch The check is narrower than "every lazy load", by design: - **Single-model results.** When the builder hydrates rows, it marks each model as lazy-load-protected **only if the result had more than one row**. `Post::find(1)->author` or `Post::first()->author` still lazy loads, because loading one relation for one model is not an N+1. - **New and just-created models.** Models built with `new` or `create()` are not hydrated from a query, so they carry no flag, and without a custom handler the violation path also returns quietly for a model that does not exist yet or was created in this request (`wasRecentlyCreated`). - **Relation method calls.** `$post->comments()->where(...)->get()` is an explicit query you asked for, not a lazy load, so it never trips the check, even inside a loop. - **Relations already loaded.** `with()`, `load()`, `loadMissing()` and `$with` set the relation, so reading it is free and allowed. - **Automatic eager loading.** If `Model::automaticallyEagerLoadRelationships()` is also on, Eloquent tries the autoloader first; when it loads the relation for the collection, no violation is raised. ## Production: throw, log, or skip The docs pattern disables the check in production so an eager load missed in review does not turn a slow page into a failing one. The cost is that production then hides the very N+1 you wanted to see. The middle path is a handler: ```php Model::preventLazyLoading(); Model::handleLazyLoadingViolationUsing(function (Model $model, string $relation) { if (app()->isProduction()) { logger()->warning('Lazy loaded relation', [ 'model' => $model::class, 'relation' => $relation, ]); return; } throw new \Illuminate\Database\LazyLoadingViolationException($model, $relation); }); ``` When a handler is registered, Eloquent calls it instead of throwing, and after it returns the relation is lazy loaded as usual. Tests and local runs still fail loudly; production records the violation and keeps serving. ## `shouldBeStrict()` bundles three checks | Called by `shouldBeStrict()` | Catches | |---|---| | `preventLazyLoading()` | an unloaded relation read as a property on a multi-row result | | `preventSilentlyDiscardingAttributes()` | mass assignment of keys that are not fillable, which are otherwise dropped silently | | `preventAccessingMissingAttributes()` | reading an attribute that was not selected, such as `email` after `with('author:id,name')`, via `MissingAttributeException` | `Model::shouldBeStrict(! $this->app->isProduction())` enables all three at once; each can still be toggled on its own. ## From exception to fix The exception names the model and the relation, for example `Attempted to lazy load [author] on model [App\Models\Post] but lazy loading is disabled.` The right fix depends on where the read happens: - **A loop in a view or controller**: add the relation to the query that built the collection, `Post::with('author')`. - **Shared code that may receive loaded or unloaded models**: `loadMissing('author')` on the collection it receives. - **A total shown per row**: an aggregate (`loadCount('comments')`) instead of reading the relation. - **A child reading back to its parent**: `chaperone()` on the parent's `hasMany`, so the inverse is set without a query. - **A relation needed only on some rows**: still load it for the collection; a batched query for all rows is cheaper than one per row that needs it. Resist the quick fix of calling `load()` inside the loop: it silences the exception while keeping one query per row. ## Rolling it out on an existing codebase 1. Enable it in local and testing environments first; the test suite becomes the list of violations. 2. Fix each by adding the relation to the query that produced the collection, not by calling `load()` inside the loop. 3. Add a production handler that logs, and watch for relations your tests never exercised. 4. Once the log stays quiet, decide whether production should throw too. The judgment interviewers look for is this trade: an exception is the fastest feedback, but a page that errors in production is worse than a page that is slow.