Angular依賴注入的類型安全漏洞，我動手修好了

LinkedIn上的一項投票顯示，開發(fā)者使用Angular依賴注入主要有兩種方式。雖然還有其他同樣有效的視角，但這個結(jié)果本身就很有意思——尤其是考慮到受訪者大多是經(jīng)驗豐富的開發(fā)者。

第一種方式是把所有服務(wù)都注冊為root級別，全局可用。第二種則是在組件或路由級別局部提供服務(wù)。從個人經(jīng)驗來說，我更傾向后者，但它目前有個危險缺陷：如果服務(wù)未被提供，Angular會在運行時崩潰，而且并非所有缺失提供者的場景都能被測試覆蓋。

一些采用第一種方式的開發(fā)者告訴我，他們從未深入研究過局部服務(wù)。這并不奇怪。Angular的DI系統(tǒng)一旦涉及局部服務(wù)，理解難度陡增。Thomas Laforge的文章《How Angular Dependency Injection works under the hood》幫了大忙，但即便有經(jīng)驗，我仍然會忘記提供服務(wù)，或者誤以為上游已提供，直到運行時才發(fā)現(xiàn)問題。

這不是技術(shù)能力問題，而是Angular最大的弱點之一：依賴注入缺乏類型安全。組件依賴的服務(wù)是隱式的、未被追蹤的。導(dǎo)入組件時，沒有任何機制告訴你它依賴哪些服務(wù)，以及那些服務(wù)又依賴什么。

局部服務(wù)的核心優(yōu)勢在于更好的職責(zé)分離，與基于特性的架構(gòu)高度契合。它們跟隨組件或路由的生命周期，能實現(xiàn)自動清理。有時你需要服務(wù)在單個特性內(nèi)共享，而非全局共享——這就是特性級局部服務(wù)的價值。

我的偏好是把邏輯盡可能局部化：組件內(nèi)隔離的邏輯用純函數(shù)；可復(fù)用但不需要DI的邏輯仍是函數(shù)；需要測試或與子組件共享的特性邏輯用組件級服務(wù)；路由范圍內(nèi)共享的用路由級服務(wù)；最后才是全局服務(wù)。

https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2026%2F0507%2F28c21f63g00teoa8o00p8d000hm00dcp.gif&thumbnail=660x2147483647&quality=80&type=jpg

這種分層思路清晰，但Angular的類型系統(tǒng)并不保護你。依賴關(guān)系在編譯期不可見，運行時才能暴露問題。對于追求可靠性的團隊，這成了選擇全局服務(wù)的理由——犧牲架構(gòu)靈活性換取確定性。

修復(fù)方向很明確：讓依賴關(guān)系在類型層面可追蹤。當(dāng)組件A依賴服務(wù)B，而B又依賴C時，這套鏈條應(yīng)該在編譯期就能被驗證，而非等到用戶點擊按鈕時崩潰。類型安全不是錦上添花，是基礎(chǔ)設(shè)施級別的需求。