昨天按照手冊(cè)教程，動(dòng)手寫(xiě)一個(gè)Auth擴(kuò)展，按照包獨(dú)立性的原則，我不希望將Auth::extend()這種方法寫(xiě)在 start.php 中,毫無(wú)疑問(wèn)，我選擇了在服務(wù)提供器register()方法中注冊(cè)擴(kuò)展驅(qū)動(dòng)。然而，事與愿違……

發(fā)現(xiàn)問(wèn)題

當(dāng)我在 LoauthServiceProvider 中這樣寫(xiě)的時(shí)候：

報(bào)錯(cuò)

尋找原因

當(dāng)時(shí)就納悶了，找原因，懷疑是Auth沒(méi)注冊(cè)？檢查發(fā)現(xiàn)注冊(cè)了，因?yàn)樵诼酚芍锌梢允褂?；php artisan clear-compiled 沒(méi)用；百思不得其解，甚至懷疑是我不小心修改了核心類(lèi)，還重新下載了一次laravel包，問(wèn)題依舊。

折騰了一晚上，最終我把目光鎖定在 AuthServiceProvider 的 $defer 屬性。

根據(jù)手冊(cè)以及注釋?zhuān)覀兊弥?$defer 屬性是用來(lái)延遲加載該服務(wù)提供器，說(shuō)直白點(diǎn)就是延遲執(zhí)行 register() 方法，只需要配合provides()方法即可實(shí)現(xiàn)。舉個(gè)例子：

這個(gè)是 AuthServiceProvider 里的方法，當(dāng)框架初始化的時(shí)候，會(huì)依次加載服務(wù)提供器，如果發(fā)現(xiàn)這個(gè)服務(wù)提供器protected $defer=true 那么就會(huì)調(diào)用它的 provides() 方法，其返回的數(shù)組包含需要延遲加載的服務(wù)名稱(chēng),這樣當(dāng)我們?cè)诼酚伞⒖刂破骰蛘咂渌胤秸{(diào)用 Auth::METHOD() 的時(shí)候，才會(huì)去調(diào)用提供器的 register() 方法。

確定癥結(jié)

那么問(wèn)題來(lái)了，既然是被動(dòng)延遲加載，也就是說(shuō)當(dāng)我調(diào)用Auth類(lèi)方法時(shí)應(yīng)該會(huì)自動(dòng)實(shí)例化Auth類(lèi)啊，為什么我在LoauthServiceProvider中調(diào)用的時(shí)候卻提示方法不存在，但是在路由中卻可以呢。

我猜測(cè)是因?yàn)閮?yōu)先級(jí)的問(wèn)題，可能在框架注冊(cè) LoauthServiceProvider::register() 的時(shí)候，Auth 還沒(méi)有標(biāo)記為延遲加載，這就造成了一個(gè)先后問(wèn)題，任何即時(shí)加載的服務(wù)提供器都無(wú)法在register方法中調(diào)用延遲加載的服務(wù)。

經(jīng)過(guò)研究，順利在核心代碼中找到證據(jù) Illuminate\Foundation\ProviderRepository

解決之道

雖然發(fā)現(xiàn)了問(wèn)題所在，但并不代表問(wèn)題就解決了，修改核心代碼不是個(gè)明智的選擇，所以只能在我們自己的包里想辦法咯，一個(gè)解決方案如下：

既然auth還未注冊(cè)，那么我們手動(dòng)調(diào)用它的register方法幫它注冊(cè)。

以上就是本文的全部?jī)?nèi)容了，希望大家能夠喜歡。