Eloquent'te N+1'i erken yakalamak için Model::preventLazyLoading'i yalnızca lokalde mi yoksa production'da da mı açmalıyım?

Kısa cevap: Lokal ve CI’da tam katı (throw) çalıştırın; production’da açık tutun ama fatal fırlatmak yerine log’layan bir handler’a bağlayın. Endişeniz haklı — ham hâliyle production’a soğuk açmak, latent bir bug’ı anında outage’a çevirir.

Buradaki tuzak, bunu ikili bir “lokal mı, production mı” anahtarı gibi düşünmektir. İşe yarayan sürüm, aynı ayarın ortama göre farklı davranmasıdır — bir geliştiricinin düzeltebileceği yerde gürültülü, gerçek bir kullanıcının 500 yiyeceği yerde sessiz.

1. Ayarın ne yaptığını netleştirin. Model::preventLazyLoading() herhangi bir lazy load denemesinde LazyLoadingViolationException fırlatır. Geliştirmede harikadır; ama test’lerinizin görmediği bir yolda gerçek bir kullanıcıya 500 döndürürse felakettir.
2. Ortama göre koşullayın. AppServiceProvider::boot() içinde Model::preventLazyLoading(! $this->app->isProduction()) deyin. Böylece production dışında her yerde katı, production’da ise throw kapalı olur.
3. Production’da throw yerine handler ile log’layın. Model::handleLazyLoadingViolationUsing(...) ile ihlali Sentry/log’a model + ilişki adıyla raporlayın ama isteği çökertmeyin. N+1’i production telemetrisinde görmeye devam eder, kullanıcıyı cezalandırmazsınız.
4. Bu üç katı ayardan biridir. preventSilentlyDiscardingAttributes ve preventAccessingMissingAttributes ile birlikte Model::shouldBeStrict() altında paketlenir. shouldBeStrict() üçünü birden açar; hepsini bilinçli açın, körlemesine değil. Diğer ikisi production’da daha düşük risklidir; ama gerçek bir kullanıcı isteğinde fırlatabilen tek ayar preventLazyLoading’dir, ayrı handler muamelesini o hak eder.
5. Yalnızca lazy load’ları yakalar, her N+1’i değil. Döngü içinde çalışan, ilişki lazy-load’u olmayan bir sorgu bu mekanizmaya takılmaz. Bu yüzden test’lerinizde Telescope/Clockwork veya sorgu sayısı assertion’ları hâlâ gerekir.
6. Kademeli açın. Production’da doğrudan throw’a geçmeden önce birkaç hafta log-only modda tutun; telemetri temizlendikten sonra istersen throw’a terfi ettirin.

// app/Providers/AppServiceProvider.php
public function boot(): void
{
    Model::preventLazyLoading(! $this->app->isProduction());

    Model::handleLazyLoadingViolationUsing(function ($model, $relation) {
        report(new \RuntimeException(
            "Lazy loading tespit edildi: ".$model::class."::".$relation
        ));
        // fırlatma yok — istek normal akışına devam eder
    });
}

Sonuç: Ben olsam lokal + CI’da tam katı, production’da ise ilk haftalarda log-only handler ile açardım. Telemetri temizlendikten sonra bile production’ı log-only bırakmak çoğu ekip için yeterli; oradaki N+1’leri görüyorsunuz ama kimseyi 500 ile vurmuyorsunuz. Asıl kural: production’a katı fırlatmayı asla soğuk açmayın — önce ölçün, sonra sıkın.