我目前正在考慮很多關于依賴注入的問題，它有利有弊。一般而言，似乎一致認為在大多數情況下依賴注入是正確的選擇。我看到了它的用處以及它如何使代碼更具可讀性。因此，我試圖用盡可能多的依賴注入來創建我的類，將關注點分成多個對象。在我 70% 的日常工作中，這很好。它有效，我看到了好處。然而，剩下的 30% 讓我有些掙扎。我對依賴注入本身的概念沒有問題，但事實上我認為 PHP 確實有一些“特殊屬性”，這讓我懷疑依賴注入是正確的選擇。主要觀點似乎是使用 DI 而不是服務定位器的優點，假設您有“編譯時錯誤”而不是“運行時錯誤”。我明白，對于 Java 或 C 之類的語言，但 PHP 中沒有“編譯時錯誤”這樣的東西不會自動導致“運行時錯誤”。至少我沒有遇到過。在啟動一次的程序中，將它們的源加載到內存中并在它們被執行時一直保持在那里，我明白你為什么要使用 DI。這是有道理的，您不必（通常）擔心應用程序需要多長時間才能達到運行狀態，并且您應該（通常）有足夠的內存來保存所有代碼。所以加載所有依賴項并將它們保存在內存中似乎沒問題。但是，PHP 腳本在 Apache、NGINX 或其他上下文中使用時，每次用戶訪問時都會啟動。除此之外，我們希望我們的應用程序運行得盡可能快，用盡可能少的資源來充分利用服務器硬件。問題是，如果我每次都加載整個庫，即使我只訪問了一小部分代碼，這似乎也很浪費......（我在下面有一個例子來說明我的意思）如上所述，我嘗試盡可能多地使用 DI。但是剩下的 30% 我仍然使用服務定位器模式來處理，因為我 a.) 只需要在特定條件下的依賴項或 b.) 我訪問一個或多或少可以用全局函數替代的服務/助手類。（見下例）在這方面，我閱讀了很多關于 a.) 助手類是邪惡的 b.) 當您在類中只使用一次依賴項時，您應該將其拆分為一個單獨的類（老實說，這是我不知道的一點完全明白，因為當您使用 DI 時，您無論如何都必須創建該類，那么為什么要將它與一般類分開？）。我創建了一些虛擬代碼來展示我認為（在撰寫本文時）服務定位器（在 PHP 中）比 DI 更明智的 30%。