：生命周期、作用域與高級玩法)
1. 為什么說依賴注入是 ASP.NET Core 的“地基”我第一次接觸 ASP.NET Core 的時候最直觀的感受就是這和舊的 .NET Framework 時代寫代碼的方式完全不一樣了。以前在 ASP.NET MVC 5 里想要在控制器里用一個服務(wù)通常就是new一個出來或者借助某個靜態(tài)類、某個單例工廠去拿。那時候項目里的服務(wù)之間互相 new、互相依賴代碼耦合得像一團亂麻測試更是難以下手。而 ASP.NET Core 從出生那天起就把依賴注入DI做進了框架的骨髓里。你看到的Startup類里的ConfigureServices方法、控制器構(gòu)造函數(shù)里直接聲明接口參數(shù)、中間件里通過RequestServices獲取服務(wù)這些都是依賴注入在背后起作用?？梢哉f不搞懂依賴注入你根本沒法理解 ASP.NET Core 的應(yīng)用是怎么被組裝起來的。那依賴注入到底解決了什么問題我用一句話概括它把“創(chuàng)建依賴”這件事從你手里拿走交給你注冊的容器統(tǒng)一管理。比如你的業(yè)務(wù)服務(wù)OrderService依賴一個IOrderRepository傳統(tǒng)寫法里你必須在OrderService內(nèi)部親手new一個具體的SqlOrderRepository。一旦換了數(shù)據(jù)庫、換了實現(xiàn)方式你得跑到每一處new的地方去改。而依賴注入的做法是OrderService只需要在構(gòu)造函數(shù)里聲明“我需要一個IOrderRepository”至于這個接口到底由哪個類來實現(xiàn)、生命周期是多久全部交給容器在注冊時決定。這不只是“解耦”兩個字那么簡單。它直接改變了你組織代碼的方式。以前你寫代碼的粒度通常是“類”而現(xiàn)在你會下意識地按照“接口 實現(xiàn) 注冊”的方式來組織。你會更自然地拆出小服務(wù)、小組件每個組件只干一件事組件之間通過接口通信。這種代碼風格一旦形成習慣項目的可維護性會肉眼可見地提升。我在帶團隊的時候經(jīng)常說依賴注入不只是一個框架功能它是一套編碼思維。你理解了它再看 ASP.NET Core 的管道、中間件、配置系統(tǒng)、日志系統(tǒng)都會覺得處處相通因為這些底層機制全都建立在 DI 容器之上。反過來如果你只是照著模板抄代碼碰到“在構(gòu)造函數(shù)里注入某個服務(wù)”的寫法也只會在用到的時候照貓畫虎一旦遇到循環(huán)依賴、生命周期沖突這種疑難雜癥就會一臉懵。所以這篇文章我想把自己在實際項目里折騰依賴注入的經(jīng)驗整理出來。從核心概念、生命周期到實戰(zhàn)中繞不開的高級玩法比如工廠模式、裝飾器模式、Scope 驗證再到踩過的坑和調(diào)試技巧爭取講得既有原理又有干貨。不管你是剛接觸 ASP.NET Core 的新手還是寫著寫著總覺得哪里不對勁的老手應(yīng)該都能從里面找到一些有價值的東西。2. 從IServiceProvider說起容器到底替我們做了什么很多人上來就背“構(gòu)造函數(shù)注入”“AddScoped”“AddTransient”但這些概念背熟以后腦子里依然是一團漿糊。我的建議是先弄懂最底層的那個對象——IServiceProvider。在 ASP.NET Core 里整個應(yīng)用其實就是一個“服務(wù)集合”的組裝結(jié)果。你寫builder.Services.AddXxx()的時候本質(zhì)上是在往一個ServiceCollection里添加服務(wù)描述。這個ServiceCollection就像一張菜單列著“什么接口對應(yīng)什么實現(xiàn)以什么生命周期來創(chuàng)建”。等到應(yīng)用啟動框架根據(jù)這張菜單構(gòu)建出一個IServiceProvider實例也就是真正的“服務(wù)容器”。IServiceProvider的核心只有一個方法object GetService(Type serviceType)。你告訴它你想要什么類型它就根據(jù)之前注冊的規(guī)則幫你把這個類型以及它依賴的東西完整地實例化出來。聽起來簡單但這背后牽扯出幾個關(guān)鍵問題構(gòu)造函數(shù)里要的參數(shù)怎么來同一個服務(wù)被請求多次時是返回同一個實例還是每次都新建如果服務(wù)之間有循環(huán)依賴怎么處理我用一個生活里的類比來解釋服務(wù)容器就像一個全能中介。你要租房子解析IOrderRepository中介會根據(jù)你的需求去匹配房東具體實現(xiàn)類SqlOrderRepository。如果房子需要配家具構(gòu)造函數(shù)依賴DbContext中介還會順手聯(lián)系家具商解析DbContext把家具也安排到位。你只需要告訴中介“我要什么”剩下的一堆復雜流程都不用管。實際寫代碼的時候最常用的入口有四個IServiceProvider直接獲取服務(wù)實例IServiceScopeFactory創(chuàng)建子作用域IServiceScope作用域本身ActivatorUtilities在容器之外輔助創(chuàng)建對象同時盡量解析其依賴其中IServiceScopeFactory是很多人一開始容易忽略的。在后臺任務(wù)、控制臺應(yīng)用、或者某些需要“手動解析服務(wù)”的場景里你往往會用serviceProvider.CreateScope()創(chuàng)建一個作用域來拿服務(wù)。如果不這么做直接拿IServiceProvider.GetService(typeof(MyService))去解析一個 Scoped 服務(wù)大概率會得到一個異?；蛘吣玫揭粋€不按預期生命周期工作的實例。關(guān)于這點我踩過比較經(jīng)典的坑是在 ASP.NET Core 的 Startup 階段嘗試解析 Scoped 服務(wù)。比如有人想在Configure方法里通過app.ApplicationServices.GetServiceMyDbContext()直接拿數(shù)據(jù)庫上下文去初始化數(shù)據(jù)。運行起來會發(fā)現(xiàn)這種方式在某些版本里能拿到對象但 DbContext 的跟蹤行為、連接管理并不符合預期甚至可能因為作用域缺失導致連接沒有及時釋放。正確做法是手動創(chuàng)建一個 Scope在這個 Scope 里拿 DbContext 用用完釋放。這個細節(jié)我在后面的生命周期章節(jié)里還會重點展開。理解了IServiceProvider你就抓住了 DI 容器的“心臟”。后面聊生命周期、聊擴展點都是圍繞這個核心展開的。3. 生命周期三兄弟Transient、Scoped、Singleton 到底怎么選ASP.NET Core 的 DI 容器支持三種生命周期模式這恐怕是日常開發(fā)里討論最多、也最容易出問題的地方。先說定義再說我的理解最后講實操選擇。生命周期創(chuàng)建時機特點典型場景Transient瞬態(tài)每次從容器解析時都新建實例最輕、無狀態(tài)輕量工具類、無狀態(tài)服務(wù)Scoped作用域每個作用域內(nèi)只創(chuàng)建一個實例一個請求一個實例DbContext、業(yè)務(wù)服務(wù)Singleton單例整個應(yīng)用生命周期內(nèi)只有一個實例全局共享緩存、配置、日志提供者定義大家都懂但實際選擇時經(jīng)常有爭議。我覺得關(guān)鍵要把握兩條原則有沒有狀態(tài)狀態(tài)的生命周期應(yīng)該有多長Singleton適合“無狀態(tài)或有意共享狀態(tài)”的服務(wù)。比如一個MemoryCache包裝類全局只有一個實例里面的數(shù)據(jù)在所有請求之間共享這很合理。但如果你把一個有狀態(tài)的類比如包含可變字段的服務(wù)注冊成 Singleton就要警惕多線程并發(fā)問題。多個請求同時讀寫同一個實例的字段輕則數(shù)據(jù)錯亂重則出現(xiàn)難以復現(xiàn)的 bug。Scoped適合“一個請求內(nèi)保持一致”的服務(wù)。最典型的就是DbContext。一個 HTTP 請求里你可能會在多個地方使用數(shù)據(jù)庫上下文如果每個地方都拿到不同的 DbContext 實例那么它們各自跟蹤不同的實體狀態(tài)事務(wù)和性能都是災(zāi)難。Scoped 保證同一個請求范圍內(nèi)拿到的都是同一個實例這個問題就自然解決了。Transient適合“每次使用都獨立”的服務(wù)。比如一個EmailValidator它內(nèi)部只保存驗證規(guī)則不保存用戶狀態(tài)每次新建一個實例成本很低也無所謂共享。再比如有些服務(wù)內(nèi)部依賴了另一個 Transient 服務(wù)每次解析都需要一個干凈的組合那么 Transient 就是合適的選擇。但實際項目里經(jīng)常出現(xiàn)“看似無狀態(tài)其實有隱含狀態(tài)”的服務(wù)這是最坑的。我舉一個例子你寫了一個AuditLogger構(gòu)造函數(shù)里注入了一個IHttpContextAccessor用來記錄當前請求的用戶信息。表面上看它沒有字段、沒有狀態(tài)非常適合注冊成 Singleton。但IHttpContextAccessor本身是 Scoped 的它的內(nèi)部邏輯依賴請求上下文如果你把AuditLogger注冊成 Singleton而它又注入了 Scoped 的IHttpContextAccessor這時候容器就會拋異常。為什么因為 Singleton 的實例在應(yīng)用啟動時就創(chuàng)建了它不像請求那樣有明確的生命周期邊界。如果允許一個 Singleton 持有 Scoped 服務(wù)的引用那么這個 Scoped 服務(wù)到底是哪個請求的容器沒法回答這個問題所以干脆在注冊時就不允許這種依賴關(guān)系。這就是著名的“生命周期捕獲”問題是 ASP.NET Core DI 新手最容易踩的大坑之一。我也碰到過這種情況一個實現(xiàn)類被同時注冊成了 Scoped 和 Singleton 兩種方式代碼里有些地方用的是 Scoped 的解析有些地方用的是 Singleton 的解析。結(jié)果是同一個邏輯在某些請求里共享狀態(tài)在某些請求里又各自獨立排查問題的時候讓人非常抓狂。我后來給自己定了一條規(guī)矩同一個服務(wù)類型在整個容器中只注冊一種生命周期除非有極其特殊的需求否則絕不在多個地方用不同生命周期重復注冊。4. Scope 與請求管道為什么你的服務(wù)在一個“虛擬邊界”里工作前面反復提到“作用域Scope”這個詞對新手來說有點抽象。我盡量用最直白的方式拆開講。其實 Scope 就是容器創(chuàng)建的一組服務(wù)實例的“集合邊界”。在 ASP.NET Core 的請求管道里框架會在每個 HTTP 請求開始時自動創(chuàng)建一個 Scope并在請求結(jié)束時把它釋放。這個 Scope 里解析的所有 Scoped 服務(wù)生命周期都跟這一個請求綁定。請求開始服務(wù)創(chuàng)建請求結(jié)束服務(wù)釋放。整個過程你基本不需要手動干預框架已經(jīng)幫你處理好了。但這個“自動”背后有一個重要前提你的代碼必須沿著請求管道走。如果你的代碼是在請求之外的上下文里執(zhí)行比如后臺托管服務(wù)、定時任務(wù)、消息隊列消費者那就沒有現(xiàn)成的 Scope 可用。這時候如果你直接解析 Scoped 服務(wù)就會遇到我前面說的麻煩。我舉個例子。假定你寫了一個IHostedService在應(yīng)用啟動后每 30 秒執(zhí)行一次數(shù)據(jù)清理任務(wù)。任務(wù)里要用到MyDbContextScoped如果你直接注入MyDbContext到后臺服務(wù)構(gòu)造函數(shù)里應(yīng)用啟動時容器就會報錯因為IHostedService本身是 Singleton 的它不能依賴 Scoped 服務(wù)。解決方式是在后臺任務(wù)的每次執(zhí)行中手動創(chuàng)建 Scopepublic class CleanupHostedService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; public CleanupHostedService(IServiceScopeFactory scopeFactory) { _scopeFactory scopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using (var scope _scopeFactory.CreateScope()) { var dbContext scope.ServiceProvider.GetRequiredServiceMyDbContext(); // 執(zhí)行清理邏輯 } await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken); } } }這里的關(guān)鍵是IServiceScopeFactory本身是 Singleton 安全的你可以放心地把它注入到任何地方。每次要干活的時候用CreateScope()開一個新的“小容器”在這個小容器里解析 Scoped 服務(wù)用完立刻釋放。這樣既遵守了生命周期規(guī)則又不會出現(xiàn)“Singleton 依賴 Scoped”的沖突。我在實際項目里把這個模式用得非常頻繁尤其是寫后臺任務(wù)、定時任務(wù)、消息隊列消費者的時候?？梢赃@么理解凡是離開了 HTTP 請求管道、又需要解析 Scoped 服務(wù)的場景都要養(yǎng)成“手動開 Scope”的習慣。這不是可選項是必須項否則你拿到的要么是異常要么是行為詭異的服務(wù)實例。還有一個容易被忽略的場景你在中間件里拿服務(wù)。中間件本身是在請求管道里的所以它默認就有 Scope 的上下文。但如果你用RequestServices.GetService()和直接用構(gòu)造函數(shù)注入結(jié)果是不太一樣的。構(gòu)造函數(shù)注入的中間件實例是 Singleton 創(chuàng)建的它拿不到當前請求的 Scope 服務(wù)而通過RequestServices拿服務(wù)是在當前請求的 Scope 里拿的這才是正確姿勢。我的經(jīng)驗是中間件里如果需要依賴 Scoped 服務(wù)優(yōu)先用RequestServices不要指望構(gòu)造函數(shù)注入。構(gòu)造函數(shù)注入適合 Scoped 服務(wù)那種“每個請求都不同”的場合但中間件只有一個實例所以它沒法持有請求級別的服務(wù)引用。5. 實戰(zhàn)技巧工廠模式、裝飾器模式與條件注冊聊完生命周期我想分享幾個實際項目中經(jīng)常用到的高級玩法。這些玩法不是 AspNet Core DI 的“必學操作”但如果你經(jīng)歷過某個痛點就會知道它們有多香。5.1 工廠模式同一個接口多個實現(xiàn)怎么處理一個接口多個實現(xiàn)類是 DI 里最直接的挑戰(zhàn)。最常見的是接口IPaymentGateway有支付寶實現(xiàn)、微信支付實現(xiàn)、銀聯(lián)實現(xiàn)你想在運行時根據(jù)上下文選擇具體用哪個。最笨的辦法是把所有實現(xiàn)都注冊上去然后靠IEnumerableIPaymentGateway注入進來自己循環(huán)判斷。但這樣代碼會越寫越亂。更優(yōu)雅的方案是注冊一個工廠委托services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var providerName config[Payment:Provider]; switch (providerName) { case Alipay: return new AlipayGateway(...); case WeChat: return new WeChatGateway(...); default: throw new InvalidOperationException($Unknown provider: {providerName}); } });工廠委托的優(yōu)勢是你可以在創(chuàng)建服務(wù)時做復雜的初始化、根據(jù)配置選擇實現(xiàn)類、或者做延遲初始化。所以當你發(fā)現(xiàn)某個服務(wù)的構(gòu)造過程不只是一句new Xxx(params...)的時候就該考慮用工廠注冊來代替默認的反射構(gòu)造。5.2 裝飾器模式在不改原代碼的情況下增加橫切邏輯裝飾器模式是 DI 里用來做“橫切關(guān)注點”的利器。什么叫橫切關(guān)注點比如日志、緩存、性能監(jiān)控、故障恢復這些邏輯縱向貫穿業(yè)務(wù)代碼把它寫在業(yè)務(wù)服務(wù)內(nèi)部會讓代碼很臟。舉個例子。你有一個IWeatherService里面提供了GetWeatherAsync。你不想改動WeatherService本身但想在每次調(diào)用時記錄耗時、加緩存、做重試。這時候你寫一個LoggingWeatherService它實現(xiàn)同一個接口內(nèi)部包裝一個真實的IWeatherServicepublic class LoggingWeatherService : IWeatherService { private readonly IWeatherService _inner; private readonly ILoggerLoggingWeatherService _logger; public LoggingWeatherService(IWeatherService inner, ILoggerLoggingWeatherService logger) { _inner inner; _logger logger; } public async TaskWeatherResult GetWeatherAsync(string city) { var sw Stopwatch.StartNew(); try { return await _inner.GetWeatherAsync(city); } finally { _logger.LogInformation(GetWeatherAsync took {Elapsed}ms, sw.ElapsedMilliseconds); } } }注冊的時候稍微繞一下services.AddTransientWeatherService(); // 真實實現(xiàn) services.AddTransientIWeatherService(sp new LoggingWeatherService(sp.GetRequiredServiceWeatherService(), sp.GetRequiredServiceILoggerLoggingWeatherService()));雖然代碼看起來多了一點點但好處是業(yè)務(wù)邏輯類根本不知道日志的存在日志邏輯獨立成一個類可復用、可測試。如果你用 Scrutor 這類庫還能自動掃描程序集批量給所有實現(xiàn)了某個接口的類套上裝飾器省去大量手工注冊代碼。我在項目里用裝飾器做過緩存、重試、審計、分布式鎖等橫切能力效果非常棒。它和 AOP面向切面編程的思想一致但在 .NET 世界里不需要引入復雜的 AOP 框架用 DI 原生的方式就能實現(xiàn)。5.3 條件注冊根據(jù)運行時配置決定要不要注冊某個服務(wù)依賴注入的條件注冊不一定要用第三方庫簡單的判斷完全可以在ConfigureServices里完成if (environment.IsDevelopment()) { services.AddScopedINotificationSender, FakeNotificationSender(); } else { services.AddScopedINotificationSender, EmailNotificationSender(); }這種寫法最常見于“開發(fā)環(huán)境用假數(shù)據(jù)/假服務(wù)生產(chǎn)環(huán)境用真實服務(wù)”的場景。不過我建議盡量少用這種分支邏輯因為它會讓注冊信息分散、難審計。更規(guī)范的做法是把不同環(huán)境的注冊邏輯封裝成IServiceCollection擴展方法按環(huán)境命名比如AddFakeNotificationServices()和AddRealNotificationServices()然后在Program.cs里按環(huán)境調(diào)用。6. 調(diào)試與性能IEnumerable 注入、驗證作用域與避免頻繁解析依賴注入用多了你會發(fā)現(xiàn)大部分問題不是“不會用”而是“出問題時不知道怎么查”。這一章我聊聊調(diào)試和性能優(yōu)化的一些實操經(jīng)驗。6.1 所有注冊的服務(wù)都能通過IEnumerableT獲取在 ASP.NET Core 的容器里如果你注冊了多個IFoo的實現(xiàn)那么注入IEnumerableIFoo時會拿到所有注冊的實例順序按照注冊順序。這個特性有兩個常見的用途實現(xiàn)某種“策略集合”循環(huán)調(diào)用每個策略。典型的例子是多個校驗器按順序執(zhí)行直到有一個不通過。做插件化架構(gòu)時動態(tài)加載程序集里所有實現(xiàn)了某個接口的類然后統(tǒng)一注冊統(tǒng)一解析。我見過不少人為了拿到多個實現(xiàn)自己維護一個列表清單然后在注冊時逐個 new。其實完全可以依賴容器本身用IEnumerableT注入。但注意這個特性和“按名字獲取具體實現(xiàn)”不一樣。如果你需要“根據(jù) key 精確獲取某一個”還是得回到工廠模式或字典映射。6.2 啟動時驗證作用域把問題暴露在啟動階段而不是請求階段ASP.NET Core 提供了ValidateScopes選項用于在啟動時檢測“從根容器解析 Scoped 服務(wù)”這類錯誤。開發(fā)環(huán)境下默認是開啟的生產(chǎn)環(huán)境默認是關(guān)閉的出于性能考慮。但如果你吃了“Singleton 依賴 Scoped”的虧建議在生產(chǎn)環(huán)境也開啟這個驗證代價只是啟動時稍微多做一點檢查但能在部署早期就把問題暴露出來。在 .NET 6 的程序里可以這樣配置var builder WebApplication.CreateBuilder(args); builder.Host.UseDefaultServiceProvider(options { options.ValidateScopes true; // 驗證作用域 options.ValidateOnBuild true; // 啟動時構(gòu)建驗證 });ValidateOnBuild更狠一點會在容器構(gòu)建完成后立即嘗試解析所有注冊的服務(wù)檢查構(gòu)造函數(shù)依賴是否都能滿足、有沒有明顯的循環(huán)依賴。這個對大型項目特別友好因為很多問題不用等到運行時請求才暴露。我記得有一次在重構(gòu)一個老項目把幾個服務(wù)從靜態(tài)類改成 DI 注冊結(jié)果啟動到一個數(shù)據(jù)庫服務(wù)時總是報“Unable to resolve service”錯誤。打開ValidateOnBuild后啟動日志直接把缺失依賴的服務(wù)名打印得清清楚楚我順著依賴鏈一個個補注冊十分鐘就搞定了。以前要是靠跑起來之后某個請求才觸發(fā)那排查時間得多花好幾倍。6.3 性能陷阱頻繁從 IServiceProvider 解析不是免費的IServiceProvider.GetService()的解析成本雖然不算高但也絕不是零成本。在熱路徑比如循環(huán)、高頻接口調(diào)用里反復解析服務(wù)會造成可感知的 CPU 開銷。我見過一個性能問題某個中間件在每次請求里用了十幾次RequestServices.GetService()雖然每次只有微秒級消耗但疊加到每秒幾萬請求的規(guī)模上浪費就很明顯了。最直接的優(yōu)化方式是把服務(wù)依賴挪到構(gòu)造函數(shù)里注入而不是在方法內(nèi)部每次解析。對于必須動態(tài)解析的場景比如策略模式、選路邏輯可以將解析結(jié)果緩存到一個局部變量中循環(huán)外解析循環(huán)內(nèi)復用。6.4 陷阱容器釋放順序與 IDisposable服務(wù)如果實現(xiàn)了IDisposable容器負責在生命周期結(jié)束時釋放它。Singleton 在應(yīng)用停止時釋放Scoped 在請求結(jié)束時釋放Transient 在解析者釋放時釋放如果解析者沒有釋放容器也會在 Scope 釋放時統(tǒng)一釋放。關(guān)于這塊有個容易被誤解的點如果你手動new出來一個服務(wù)沒有經(jīng)過容器容器是不知道也不負責釋放的你需要自己管理它的生命周期。還有一個小坑如果你用工廠注冊AddTransientIFoo(sp new Foo())返回一個實現(xiàn)了IDisposable的對象容器會跟蹤并釋放它前提是它是在容器解析時創(chuàng)建的。如果你的工廠返回的是一個已經(jīng)存在的單例比如靜態(tài)實例容器可能會重復釋放同一個對象這時候要格外小心。經(jīng)驗是讓容器管理生命周期不要在工廠里返回自己管理生命周期的“外來對象”除非你確認不會出現(xiàn)重復釋放問題。7. 架構(gòu)層面的實踐接口、模塊化注冊與可測試性依賴注入的最終勝利不在于“會用”而在于“用得順手”。我自己在架構(gòu)層面有幾條心得分享給大家。7.1 每個項目都按模塊拆分注冊擴展方法我參與過的項目中最容易失控的是那個巨無霸Program.cs或Startup.cs。幾十個AddSomething()擠在一起誰也不敢動改一行都心驚膽戰(zhàn)。后來我養(yǎng)成了一個習慣每個業(yè)務(wù)模塊自己寫一個服務(wù)注冊擴展方法內(nèi)部只負責本模塊依賴的服務(wù)然后在Program.cs里調(diào)用它。舉個例子一個“訂單模塊”可以有一個public static class OrderServiceCollectionExtensions { public static IServiceCollection AddOrderModule(this IServiceCollection services) { services.AddScopedIOrderRepository, SqlOrderRepository(); services.AddScopedIOrderService, OrderService(); services.AddScopedIOrderDomainEventHandler, OrderDomainEventHandler(); return services; } }Program.cs里三五行就搞定builder.Services.AddInfrastructureModule(); builder.Services.AddOrderModule(); builder.Services.AddPaymentModule();這樣每個模塊的依賴關(guān)系集中在模塊自己的擴展方法里找問題的時候直接進模塊文件不用在啟動文件里撈針。配合上模塊化項目的層次結(jié)構(gòu)應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層、表現(xiàn)層每一層的 DI 注冊職責也能被清晰劃分。7.2 用容器做依賴注入但也別把一切都扔進容器有一類東西我不建議放容器里。比如配置對象直接用IOptionsT、靜態(tài)工具類如MathHelper、簡單的數(shù)據(jù)傳輸對象DTO。容器存在的意義是管理復雜依賴關(guān)系和生命周期如果什么東西都硬塞進容器解析鏈會越來越長性能下降排查也麻煩。還有一類需要小心的是“長期存在的服務(wù)”和“短期請求”混合的情況。比如 Singleton 的緩存服務(wù)里不小心引用了 Scoped 的DbContext這就是架構(gòu)層面的錯誤。我給出的建議很簡單畫一條依賴規(guī)則——Singleton 只能依賴 SingletonScoped 可以依賴 Scoped 和 SingletonTransient 可以依賴任意生命周期。寫進團隊規(guī)范當作評審時的關(guān)注點。7.3 依賴注入如何讓測試變得更簡單依賴注入最大的工程紅利是“可測試性”。因為一個類的依賴都是通過接口注進來的測試時你可以隨手替換成假的實現(xiàn)不需要啟動整個應(yīng)用不需要碰數(shù)據(jù)庫不需要真實發(fā)郵件。我寫單元測試時的做法是[Fact] public async Task GetWeatherAsync_WhenCityIsEmpty_ThrowsArgumentException() { var weatherService new WeatherService( Mock.OfIWeatherRepository(), Mock.OfICacheService()); await Assert.ThrowsAsyncArgumentException( () weatherService.GetWeatherAsync()); }這里每個依賴都能用 mock 對象替代測試用例短小明確。如果沒有依賴注入你可能要花大力氣構(gòu)造WeatherService的內(nèi)部依賴甚至要起一個完整的服務(wù)宿主測試效率和可維護性都差很多。7.4 依賴注入與模塊化邊界別讓容器變成“上帝對象”有一種反模式是為了讓某個服務(wù)在任何地方都能拿到把它注冊成 Singleton然后在幾乎每個類里注入它。這會造成隱式的全局依賴代碼之間通過這個“上帝對象”互相通信模塊邊界名存實亡。我在一些老項目里見過這種現(xiàn)象整改起來特別痛苦。正確的做法是依賴關(guān)系要顯式地通過構(gòu)造函數(shù)表達出來。如果一個類需要“當前用戶信息”不要讓它自己去全局容器里拿而是讓調(diào)用方把用戶信息顯式傳進來。容器只用來組裝那些“真正需要容器管理的服務(wù)”不要用它作為傳遞參數(shù)的通道。這一點做得好模塊邊界才能保持清晰。8. 那些坑循環(huán)依賴、作用域失控與我沒能早發(fā)現(xiàn)的錯誤最后一個大章節(jié)聊幾個實際項目中經(jīng)常踩的坑。這些坑每個我都見過或者親身體驗過希望你們能提前避雷。8.1 循環(huán)依賴兩個服務(wù)互相引用彼此依賴注入最經(jīng)典的報錯之一A依賴BB又依賴A。容器在嘗試解析時會發(fā)現(xiàn)依賴鏈成了一個環(huán)然后拋出異常。解決辦法一般有三種重構(gòu)拆分把 A 和 B 之間互相依賴的那部分邏輯抽出來放到第三個類 C 里A 和 B 都依賴 C循環(huán)自然解除。這是最徹底的方案也是我最推薦的方式。改變生命周期如果 A 和 B 都是 Transient改成其中一個為 Singleton 或 Scoped有時能繞過構(gòu)建循環(huán)的問題。但這治標不治本潛在風險仍然在。延遲解析某個服務(wù)在真正用到時才去容器解析通過注入IServiceProvider而不是在構(gòu)造函數(shù)里直接依賴。可以解決問題但代價是“依賴關(guān)系變隱式了”而且會破壞構(gòu)造函數(shù)注入的清晰性。我的經(jīng)驗是遇到循環(huán)依賴先停下來想想設(shè)計問題而不是急著找 hack。循環(huán)依賴通常意味著職責邊界劃分不當。重構(gòu)雖然工作量大一點但以后維護的舒適度完全值得。8.2 作用域失控一個 Scoped 服務(wù)被 Singleton 持有了這個坑我在生命周期章節(jié)提過但值得再具體演示一下。假設(shè)你有一個ICacheService注冊成了 Singleton而它內(nèi)部注入了IBillingRepositoryScoped。容器啟動時不會立刻檢測到錯誤除非開啟了ValidateOnBuild但等到某個請求使用了這個緩存服務(wù)運行時就會拋出異常。這類問題最陰險的地方是它不一定在啟動階段出現(xiàn)而是取決于哪個請求先觸發(fā)。A 客戶端的請求觸發(fā)了一切正常B 客戶端的請求觸發(fā)了直接 500。我見過一個項目因為這個原因偶發(fā)崩潰排查了好久才定位到這層關(guān)系。最好的防線就是我在前面說的同一個服務(wù)生命周期統(tǒng)一Singleton 依賴鏈上全部是 Singleton在開發(fā)環(huán)境開啟服務(wù)作用域驗證。這三條做到了這類坑基本能全部躲掉。8.3 過度注入構(gòu)造函數(shù)動不動就七八個參數(shù)如果一個服務(wù)類構(gòu)造函數(shù)里要注入七八個東西這個類八成違背了“單一職責原則”。七八個依賴意味著它同時在做好幾件事。我見過最夸張的某個服務(wù)構(gòu)造函數(shù)里塞了 12 個依賴每次修改都要傳新參數(shù)測試時 mock 也要寫 12 行。重構(gòu)思路是拆類把數(shù)據(jù)庫訪問拆出去、把通知拆出去、把緩存拆出去然后用門面模式或組合模式把幾個小服務(wù)組合起來。依賴注入容器擅長組裝所以“很多小對象組合成一個大對象”是合理的但“一個大對象硬吞進無數(shù)依賴”是不合理的。8.4 忘記釋放 scope 資源在手動創(chuàng)建 Scope 的場景里后臺任務(wù)、控制臺應(yīng)用如果忘記using釋放 ScopeScoped 服務(wù)里創(chuàng)建的DbContext、HTTP 客戶端連接等資源就會一直占著內(nèi)存時間長了可能引發(fā)連接池耗盡、內(nèi)存泄漏。我給自己定的習慣是所有手動創(chuàng)建的 Scope 一律用using或await using包起來確保離開代碼塊就釋放。哪怕只是解析一個不痛不癢的小服務(wù)也養(yǎng)成這個習慣免得哪天換成DbContext時踩雷。8.5 啟動時解析 Scoped 服務(wù)的“想當然”錯誤前面說過在Program.cs或Startup.cs里直接解析 Scoped 服務(wù)是個常見的坑。比如有人想在啟動時初始化 admin 用戶var adminService app.Services.GetRequiredServiceIAdminService(); adminService.Initialize();如果IAdminService注冊的是 Scoped這段代碼會直接報錯未開啟ValidateScopes時也可能不報錯但行為不保證。正確寫法using (var scope app.Services.CreateScope()) { var adminService scope.ServiceProvider.GetRequiredServiceIAdminService(); adminService.Initialize(); }這個“手動開 Scope 解析服務(wù)”的模式在 .NET 6 的WebApplication環(huán)境里尤其常見因為Program.cs里寫啟動邏輯的人很多。記住一條根容器的ApplicationServices是用來解析 Singleton 和通過工廠解析服務(wù)的不是給你解析 Scoped 服務(wù)的。9. 我的推薦實踐從開發(fā)到生產(chǎn)環(huán)境一路穩(wěn)最后我給出一份我在實際項目里會用的“依賴注入實踐清單”。這些條不是什么金科玉律但經(jīng)過多個項目的錘煉確實能幫我少踩很多坑。注冊入口盡量集中在模塊擴展方法里不要在Program.cs里散落大量注冊代碼。每個模塊對自己負責注冊代碼的查找成本極大降低。生命周期統(tǒng)一且顯式同一個服務(wù)類型只注冊一種生命周期。注冊 Unity 時團隊規(guī)范里寫明“所有服務(wù)必須顯式指定生命周期”不允許使用默認的自動注冊工具把一切都變成 Transient 或 Singleton。在開發(fā)環(huán)境和生產(chǎn)環(huán)境都開啟ValidateScopes。雖然生產(chǎn)環(huán)境有一些性能開銷但換來的是早期發(fā)現(xiàn)生命周期錯誤。如果對性能極度敏感可以在生產(chǎn)環(huán)境關(guān)閉但要保證測試和預發(fā)布環(huán)境開啟。堅持構(gòu)造函數(shù)注入避免屬性注入和服務(wù)定位器模式。構(gòu)造函數(shù)注入最顯式依賴關(guān)系一目了然。雖然屬性注入寫起來更少但“依賴關(guān)系隱式化”后代碼的可讀性和可測性會變差。使用IOptionsT來管理配置不要直接把配置對象注冊成 Singleton。這樣配置的刷新、熱更新才有標準支持測試時替換配置也更靈活。對資源型服務(wù)比如 DbContext、數(shù)據(jù)庫連接優(yōu)先使用 Scoped并且確保在請求管道或手動 Scope 里使用。如果需要在后臺任務(wù)里使用就手動創(chuàng)建并釋放 Scope。依賴方向只允許單向流動接口定義在一個模塊實現(xiàn)放在基礎(chǔ)設(shè)施層應(yīng)用層只依賴接口。這樣 Web API、后臺任務(wù)、測試都能共用同一個接口層模塊之間的耦合被降到最低。定期做依賴關(guān)系審計可以寫一個簡單的構(gòu)建腳本在 CI 階段把服務(wù)注冊列表輸出到日志里看看有沒有某個模塊的注冊依賴異常。這個對團隊協(xié)作特別有幫助。我可以坦誠地說依賴注入這套機制我自己從“會用”到“覺得香”經(jīng)歷了挺長時間。很多經(jīng)驗也是靠踩坑換來的——特別是那幾個生命周期相關(guān)的坑我至今記憶猶新。希望這篇長文能幫你把 ASP.NET Core 依賴注入從“知道概念”推向“理解本質(zhì)”以后在項目里用它建模、設(shè)計服務(wù)邊界、排查疑難問題的時候能更有底氣。 ASP.NET Core依賴注入實戰(zhàn)：生命周期、作用域與高級玩法
1. 為什么說依賴注入是 ASP.NET Core 的“地基”我第一次接觸 ASP.NET Core 的時候最直觀的感受就是這和舊的 .NET Framework 時代寫代碼的方式完全不一樣了。以前在 ASP.NET MVC 5 里想要在控制器里用一個服務(wù)通常就是new一個出來或者借助某個靜態(tài)類、某個單例工廠去拿。那時候項目里的服務(wù)之間互相 new、互相依賴代碼耦合得像一團亂麻測試更是難以下手。而 ASP.NET Core 從出生那天起就把依賴注入DI做進了框架的骨髓里。你看到的Startup類里的ConfigureServices方法、控制器構(gòu)造函數(shù)里直接聲明接口參數(shù)、中間件里通過RequestServices獲取服務(wù)這些都是依賴注入在背后起作用?？梢哉f不搞懂依賴注入你根本沒法理解 ASP.NET Core 的應(yīng)用是怎么被組裝起來的。那依賴注入到底解決了什么問題我用一句話概括它把“創(chuàng)建依賴”這件事從你手里拿走交給你注冊的容器統(tǒng)一管理。比如你的業(yè)務(wù)服務(wù)OrderService依賴一個IOrderRepository傳統(tǒng)寫法里你必須在OrderService內(nèi)部親手new一個具體的SqlOrderRepository。一旦換了數(shù)據(jù)庫、換了實現(xiàn)方式你得跑到每一處new的地方去改。而依賴注入的做法是OrderService只需要在構(gòu)造函數(shù)里聲明“我需要一個IOrderRepository”至于這個接口到底由哪個類來實現(xiàn)、生命周期是多久全部交給容器在注冊時決定。這不只是“解耦”兩個字那么簡單。它直接改變了你組織代碼的方式。以前你寫代碼的粒度通常是“類”而現(xiàn)在你會下意識地按照“接口 實現(xiàn) 注冊”的方式來組織。你會更自然地拆出小服務(wù)、小組件每個組件只干一件事組件之間通過接口通信。這種代碼風格一旦形成習慣項目的可維護性會肉眼可見地提升。我在帶團隊的時候經(jīng)常說依賴注入不只是一個框架功能它是一套編碼思維。你理解了它再看 ASP.NET Core 的管道、中間件、配置系統(tǒng)、日志系統(tǒng)都會覺得處處相通因為這些底層機制全都建立在 DI 容器之上。反過來如果你只是照著模板抄代碼碰到“在構(gòu)造函數(shù)里注入某個服務(wù)”的寫法也只會在用到的時候照貓畫虎一旦遇到循環(huán)依賴、生命周期沖突這種疑難雜癥就會一臉懵。所以這篇文章我想把自己在實際項目里折騰依賴注入的經(jīng)驗整理出來。從核心概念、生命周期到實戰(zhàn)中繞不開的高級玩法比如工廠模式、裝飾器模式、Scope 驗證再到踩過的坑和調(diào)試技巧爭取講得既有原理又有干貨。不管你是剛接觸 ASP.NET Core 的新手還是寫著寫著總覺得哪里不對勁的老手應(yīng)該都能從里面找到一些有價值的東西。2. 從IServiceProvider說起容器到底替我們做了什么很多人上來就背“構(gòu)造函數(shù)注入”“AddScoped”“AddTransient”但這些概念背熟以后腦子里依然是一團漿糊。我的建議是先弄懂最底層的那個對象——IServiceProvider。在 ASP.NET Core 里整個應(yīng)用其實就是一個“服務(wù)集合”的組裝結(jié)果。你寫builder.Services.AddXxx()的時候本質(zhì)上是在往一個ServiceCollection里添加服務(wù)描述。這個ServiceCollection就像一張菜單列著“什么接口對應(yīng)什么實現(xiàn)以什么生命周期來創(chuàng)建”。等到應(yīng)用啟動框架根據(jù)這張菜單構(gòu)建出一個IServiceProvider實例也就是真正的“服務(wù)容器”。IServiceProvider的核心只有一個方法object GetService(Type serviceType)。你告訴它你想要什么類型它就根據(jù)之前注冊的規(guī)則幫你把這個類型以及它依賴的東西完整地實例化出來。聽起來簡單但這背后牽扯出幾個關(guān)鍵問題構(gòu)造函數(shù)里要的參數(shù)怎么來同一個服務(wù)被請求多次時是返回同一個實例還是每次都新建如果服務(wù)之間有循環(huán)依賴怎么處理我用一個生活里的類比來解釋服務(wù)容器就像一個全能中介。你要租房子解析IOrderRepository中介會根據(jù)你的需求去匹配房東具體實現(xiàn)類SqlOrderRepository。如果房子需要配家具構(gòu)造函數(shù)依賴DbContext中介還會順手聯(lián)系家具商解析DbContext把家具也安排到位。你只需要告訴中介“我要什么”剩下的一堆復雜流程都不用管。實際寫代碼的時候最常用的入口有四個IServiceProvider直接獲取服務(wù)實例IServiceScopeFactory創(chuàng)建子作用域IServiceScope作用域本身ActivatorUtilities在容器之外輔助創(chuàng)建對象同時盡量解析其依賴其中IServiceScopeFactory是很多人一開始容易忽略的。在后臺任務(wù)、控制臺應(yīng)用、或者某些需要“手動解析服務(wù)”的場景里你往往會用serviceProvider.CreateScope()創(chuàng)建一個作用域來拿服務(wù)。如果不這么做直接拿IServiceProvider.GetService(typeof(MyService))去解析一個 Scoped 服務(wù)大概率會得到一個異?；蛘吣玫揭粋€不按預期生命周期工作的實例。關(guān)于這點我踩過比較經(jīng)典的坑是在 ASP.NET Core 的 Startup 階段嘗試解析 Scoped 服務(wù)。比如有人想在Configure方法里通過app.ApplicationServices.GetServiceMyDbContext()直接拿數(shù)據(jù)庫上下文去初始化數(shù)據(jù)。運行起來會發(fā)現(xiàn)這種方式在某些版本里能拿到對象但 DbContext 的跟蹤行為、連接管理并不符合預期甚至可能因為作用域缺失導致連接沒有及時釋放。正確做法是手動創(chuàng)建一個 Scope在這個 Scope 里拿 DbContext 用用完釋放。這個細節(jié)我在后面的生命周期章節(jié)里還會重點展開。理解了IServiceProvider你就抓住了 DI 容器的“心臟”。后面聊生命周期、聊擴展點都是圍繞這個核心展開的。3. 生命周期三兄弟Transient、Scoped、Singleton 到底怎么選ASP.NET Core 的 DI 容器支持三種生命周期模式這恐怕是日常開發(fā)里討論最多、也最容易出問題的地方。先說定義再說我的理解最后講實操選擇。生命周期創(chuàng)建時機特點典型場景Transient瞬態(tài)每次從容器解析時都新建實例最輕、無狀態(tài)輕量工具類、無狀態(tài)服務(wù)Scoped作用域每個作用域內(nèi)只創(chuàng)建一個實例一個請求一個實例DbContext、業(yè)務(wù)服務(wù)Singleton單例整個應(yīng)用生命周期內(nèi)只有一個實例全局共享緩存、配置、日志提供者定義大家都懂但實際選擇時經(jīng)常有爭議。我覺得關(guān)鍵要把握兩條原則有沒有狀態(tài)狀態(tài)的生命周期應(yīng)該有多長Singleton適合“無狀態(tài)或有意共享狀態(tài)”的服務(wù)。比如一個MemoryCache包裝類全局只有一個實例里面的數(shù)據(jù)在所有請求之間共享這很合理。但如果你把一個有狀態(tài)的類比如包含可變字段的服務(wù)注冊成 Singleton就要警惕多線程并發(fā)問題。多個請求同時讀寫同一個實例的字段輕則數(shù)據(jù)錯亂重則出現(xiàn)難以復現(xiàn)的 bug。Scoped適合“一個請求內(nèi)保持一致”的服務(wù)。最典型的就是DbContext。一個 HTTP 請求里你可能會在多個地方使用數(shù)據(jù)庫上下文如果每個地方都拿到不同的 DbContext 實例那么它們各自跟蹤不同的實體狀態(tài)事務(wù)和性能都是災(zāi)難。Scoped 保證同一個請求范圍內(nèi)拿到的都是同一個實例這個問題就自然解決了。Transient適合“每次使用都獨立”的服務(wù)。比如一個EmailValidator它內(nèi)部只保存驗證規(guī)則不保存用戶狀態(tài)每次新建一個實例成本很低也無所謂共享。再比如有些服務(wù)內(nèi)部依賴了另一個 Transient 服務(wù)每次解析都需要一個干凈的組合那么 Transient 就是合適的選擇。但實際項目里經(jīng)常出現(xiàn)“看似無狀態(tài)其實有隱含狀態(tài)”的服務(wù)這是最坑的。我舉一個例子你寫了一個AuditLogger構(gòu)造函數(shù)里注入了一個IHttpContextAccessor用來記錄當前請求的用戶信息。表面上看它沒有字段、沒有狀態(tài)非常適合注冊成 Singleton。但IHttpContextAccessor本身是 Scoped 的它的內(nèi)部邏輯依賴請求上下文如果你把AuditLogger注冊成 Singleton而它又注入了 Scoped 的IHttpContextAccessor這時候容器就會拋異常。為什么因為 Singleton 的實例在應(yīng)用啟動時就創(chuàng)建了它不像請求那樣有明確的生命周期邊界。如果允許一個 Singleton 持有 Scoped 服務(wù)的引用那么這個 Scoped 服務(wù)到底是哪個請求的容器沒法回答這個問題所以干脆在注冊時就不允許這種依賴關(guān)系。這就是著名的“生命周期捕獲”問題是 ASP.NET Core DI 新手最容易踩的大坑之一。我也碰到過這種情況一個實現(xiàn)類被同時注冊成了 Scoped 和 Singleton 兩種方式代碼里有些地方用的是 Scoped 的解析有些地方用的是 Singleton 的解析。結(jié)果是同一個邏輯在某些請求里共享狀態(tài)在某些請求里又各自獨立排查問題的時候讓人非常抓狂。我后來給自己定了一條規(guī)矩同一個服務(wù)類型在整個容器中只注冊一種生命周期除非有極其特殊的需求否則絕不在多個地方用不同生命周期重復注冊。4. Scope 與請求管道為什么你的服務(wù)在一個“虛擬邊界”里工作前面反復提到“作用域Scope”這個詞對新手來說有點抽象。我盡量用最直白的方式拆開講。其實 Scope 就是容器創(chuàng)建的一組服務(wù)實例的“集合邊界”。在 ASP.NET Core 的請求管道里框架會在每個 HTTP 請求開始時自動創(chuàng)建一個 Scope并在請求結(jié)束時把它釋放。這個 Scope 里解析的所有 Scoped 服務(wù)生命周期都跟這一個請求綁定。請求開始服務(wù)創(chuàng)建請求結(jié)束服務(wù)釋放。整個過程你基本不需要手動干預框架已經(jīng)幫你處理好了。但這個“自動”背后有一個重要前提你的代碼必須沿著請求管道走。如果你的代碼是在請求之外的上下文里執(zhí)行比如后臺托管服務(wù)、定時任務(wù)、消息隊列消費者那就沒有現(xiàn)成的 Scope 可用。這時候如果你直接解析 Scoped 服務(wù)就會遇到我前面說的麻煩。我舉個例子。假定你寫了一個IHostedService在應(yīng)用啟動后每 30 秒執(zhí)行一次數(shù)據(jù)清理任務(wù)。任務(wù)里要用到MyDbContextScoped如果你直接注入MyDbContext到后臺服務(wù)構(gòu)造函數(shù)里應(yīng)用啟動時容器就會報錯因為IHostedService本身是 Singleton 的它不能依賴 Scoped 服務(wù)。解決方式是在后臺任務(wù)的每次執(zhí)行中手動創(chuàng)建 Scopepublic class CleanupHostedService : BackgroundService { private readonly IServiceScopeFactory _scopeFactory; public CleanupHostedService(IServiceScopeFactory scopeFactory) { _scopeFactory scopeFactory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { while (!stoppingToken.IsCancellationRequested) { using (var scope _scopeFactory.CreateScope()) { var dbContext scope.ServiceProvider.GetRequiredServiceMyDbContext(); // 執(zhí)行清理邏輯 } await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken); } } }這里的關(guān)鍵是IServiceScopeFactory本身是 Singleton 安全的你可以放心地把它注入到任何地方。每次要干活的時候用CreateScope()開一個新的“小容器”在這個小容器里解析 Scoped 服務(wù)用完立刻釋放。這樣既遵守了生命周期規(guī)則又不會出現(xiàn)“Singleton 依賴 Scoped”的沖突。我在實際項目里把這個模式用得非常頻繁尤其是寫后臺任務(wù)、定時任務(wù)、消息隊列消費者的時候?？梢赃@么理解凡是離開了 HTTP 請求管道、又需要解析 Scoped 服務(wù)的場景都要養(yǎng)成“手動開 Scope”的習慣。這不是可選項是必須項否則你拿到的要么是異常要么是行為詭異的服務(wù)實例。還有一個容易被忽略的場景你在中間件里拿服務(wù)。中間件本身是在請求管道里的所以它默認就有 Scope 的上下文。但如果你用RequestServices.GetService()和直接用構(gòu)造函數(shù)注入結(jié)果是不太一樣的。構(gòu)造函數(shù)注入的中間件實例是 Singleton 創(chuàng)建的它拿不到當前請求的 Scope 服務(wù)而通過RequestServices拿服務(wù)是在當前請求的 Scope 里拿的這才是正確姿勢。我的經(jīng)驗是中間件里如果需要依賴 Scoped 服務(wù)優(yōu)先用RequestServices不要指望構(gòu)造函數(shù)注入。構(gòu)造函數(shù)注入適合 Scoped 服務(wù)那種“每個請求都不同”的場合但中間件只有一個實例所以它沒法持有請求級別的服務(wù)引用。5. 實戰(zhàn)技巧工廠模式、裝飾器模式與條件注冊聊完生命周期我想分享幾個實際項目中經(jīng)常用到的高級玩法。這些玩法不是 AspNet Core DI 的“必學操作”但如果你經(jīng)歷過某個痛點就會知道它們有多香。5.1 工廠模式同一個接口多個實現(xiàn)怎么處理一個接口多個實現(xiàn)類是 DI 里最直接的挑戰(zhàn)。最常見的是接口IPaymentGateway有支付寶實現(xiàn)、微信支付實現(xiàn)、銀聯(lián)實現(xiàn)你想在運行時根據(jù)上下文選擇具體用哪個。最笨的辦法是把所有實現(xiàn)都注冊上去然后靠IEnumerableIPaymentGateway注入進來自己循環(huán)判斷。但這樣代碼會越寫越亂。更優(yōu)雅的方案是注冊一個工廠委托services.AddScopedIPaymentGateway(serviceProvider { var config serviceProvider.GetRequiredServiceIConfiguration(); var providerName config[Payment:Provider]; switch (providerName) { case Alipay: return new AlipayGateway(...); case WeChat: return new WeChatGateway(...); default: throw new InvalidOperationException($Unknown provider: {providerName}); } });工廠委托的優(yōu)勢是你可以在創(chuàng)建服務(wù)時做復雜的初始化、根據(jù)配置選擇實現(xiàn)類、或者做延遲初始化。所以當你發(fā)現(xiàn)某個服務(wù)的構(gòu)造過程不只是一句new Xxx(params...)的時候就該考慮用工廠注冊來代替默認的反射構(gòu)造。5.2 裝飾器模式在不改原代碼的情況下增加橫切邏輯裝飾器模式是 DI 里用來做“橫切關(guān)注點”的利器。什么叫橫切關(guān)注點比如日志、緩存、性能監(jiān)控、故障恢復這些邏輯縱向貫穿業(yè)務(wù)代碼把它寫在業(yè)務(wù)服務(wù)內(nèi)部會讓代碼很臟。舉個例子。你有一個IWeatherService里面提供了GetWeatherAsync。你不想改動WeatherService本身但想在每次調(diào)用時記錄耗時、加緩存、做重試。這時候你寫一個LoggingWeatherService它實現(xiàn)同一個接口內(nèi)部包裝一個真實的IWeatherServicepublic class LoggingWeatherService : IWeatherService { private readonly IWeatherService _inner; private readonly ILoggerLoggingWeatherService _logger; public LoggingWeatherService(IWeatherService inner, ILoggerLoggingWeatherService logger) { _inner inner; _logger logger; } public async TaskWeatherResult GetWeatherAsync(string city) { var sw Stopwatch.StartNew(); try { return await _inner.GetWeatherAsync(city); } finally { _logger.LogInformation(GetWeatherAsync took {Elapsed}ms, sw.ElapsedMilliseconds); } } }注冊的時候稍微繞一下services.AddTransientWeatherService(); // 真實實現(xiàn) services.AddTransientIWeatherService(sp new LoggingWeatherService(sp.GetRequiredServiceWeatherService(), sp.GetRequiredServiceILoggerLoggingWeatherService()));雖然代碼看起來多了一點點但好處是業(yè)務(wù)邏輯類根本不知道日志的存在日志邏輯獨立成一個類可復用、可測試。如果你用 Scrutor 這類庫還能自動掃描程序集批量給所有實現(xiàn)了某個接口的類套上裝飾器省去大量手工注冊代碼。我在項目里用裝飾器做過緩存、重試、審計、分布式鎖等橫切能力效果非常棒。它和 AOP面向切面編程的思想一致但在 .NET 世界里不需要引入復雜的 AOP 框架用 DI 原生的方式就能實現(xiàn)。5.3 條件注冊根據(jù)運行時配置決定要不要注冊某個服務(wù)依賴注入的條件注冊不一定要用第三方庫簡單的判斷完全可以在ConfigureServices里完成if (environment.IsDevelopment()) { services.AddScopedINotificationSender, FakeNotificationSender(); } else { services.AddScopedINotificationSender, EmailNotificationSender(); }這種寫法最常見于“開發(fā)環(huán)境用假數(shù)據(jù)/假服務(wù)生產(chǎn)環(huán)境用真實服務(wù)”的場景。不過我建議盡量少用這種分支邏輯因為它會讓注冊信息分散、難審計。更規(guī)范的做法是把不同環(huán)境的注冊邏輯封裝成IServiceCollection擴展方法按環(huán)境命名比如AddFakeNotificationServices()和AddRealNotificationServices()然后在Program.cs里按環(huán)境調(diào)用。6. 調(diào)試與性能IEnumerable 注入、驗證作用域與避免頻繁解析依賴注入用多了你會發(fā)現(xiàn)大部分問題不是“不會用”而是“出問題時不知道怎么查”。這一章我聊聊調(diào)試和性能優(yōu)化的一些實操經(jīng)驗。6.1 所有注冊的服務(wù)都能通過IEnumerableT獲取在 ASP.NET Core 的容器里如果你注冊了多個IFoo的實現(xiàn)那么注入IEnumerableIFoo時會拿到所有注冊的實例順序按照注冊順序。這個特性有兩個常見的用途實現(xiàn)某種“策略集合”循環(huán)調(diào)用每個策略。典型的例子是多個校驗器按順序執(zhí)行直到有一個不通過。做插件化架構(gòu)時動態(tài)加載程序集里所有實現(xiàn)了某個接口的類然后統(tǒng)一注冊統(tǒng)一解析。我見過不少人為了拿到多個實現(xiàn)自己維護一個列表清單然后在注冊時逐個 new。其實完全可以依賴容器本身用IEnumerableT注入。但注意這個特性和“按名字獲取具體實現(xiàn)”不一樣。如果你需要“根據(jù) key 精確獲取某一個”還是得回到工廠模式或字典映射。6.2 啟動時驗證作用域把問題暴露在啟動階段而不是請求階段ASP.NET Core 提供了ValidateScopes選項用于在啟動時檢測“從根容器解析 Scoped 服務(wù)”這類錯誤。開發(fā)環(huán)境下默認是開啟的生產(chǎn)環(huán)境默認是關(guān)閉的出于性能考慮。但如果你吃了“Singleton 依賴 Scoped”的虧建議在生產(chǎn)環(huán)境也開啟這個驗證代價只是啟動時稍微多做一點檢查但能在部署早期就把問題暴露出來。在 .NET 6 的程序里可以這樣配置var builder WebApplication.CreateBuilder(args); builder.Host.UseDefaultServiceProvider(options { options.ValidateScopes true; // 驗證作用域 options.ValidateOnBuild true; // 啟動時構(gòu)建驗證 });ValidateOnBuild更狠一點會在容器構(gòu)建完成后立即嘗試解析所有注冊的服務(wù)檢查構(gòu)造函數(shù)依賴是否都能滿足、有沒有明顯的循環(huán)依賴。這個對大型項目特別友好因為很多問題不用等到運行時請求才暴露。我記得有一次在重構(gòu)一個老項目把幾個服務(wù)從靜態(tài)類改成 DI 注冊結(jié)果啟動到一個數(shù)據(jù)庫服務(wù)時總是報“Unable to resolve service”錯誤。打開ValidateOnBuild后啟動日志直接把缺失依賴的服務(wù)名打印得清清楚楚我順著依賴鏈一個個補注冊十分鐘就搞定了。以前要是靠跑起來之后某個請求才觸發(fā)那排查時間得多花好幾倍。6.3 性能陷阱頻繁從 IServiceProvider 解析不是免費的IServiceProvider.GetService()的解析成本雖然不算高但也絕不是零成本。在熱路徑比如循環(huán)、高頻接口調(diào)用里反復解析服務(wù)會造成可感知的 CPU 開銷。我見過一個性能問題某個中間件在每次請求里用了十幾次RequestServices.GetService()雖然每次只有微秒級消耗但疊加到每秒幾萬請求的規(guī)模上浪費就很明顯了。最直接的優(yōu)化方式是把服務(wù)依賴挪到構(gòu)造函數(shù)里注入而不是在方法內(nèi)部每次解析。對于必須動態(tài)解析的場景比如策略模式、選路邏輯可以將解析結(jié)果緩存到一個局部變量中循環(huán)外解析循環(huán)內(nèi)復用。6.4 陷阱容器釋放順序與 IDisposable服務(wù)如果實現(xiàn)了IDisposable容器負責在生命周期結(jié)束時釋放它。Singleton 在應(yīng)用停止時釋放Scoped 在請求結(jié)束時釋放Transient 在解析者釋放時釋放如果解析者沒有釋放容器也會在 Scope 釋放時統(tǒng)一釋放。關(guān)于這塊有個容易被誤解的點如果你手動new出來一個服務(wù)沒有經(jīng)過容器容器是不知道也不負責釋放的你需要自己管理它的生命周期。還有一個小坑如果你用工廠注冊AddTransientIFoo(sp new Foo())返回一個實現(xiàn)了IDisposable的對象容器會跟蹤并釋放它前提是它是在容器解析時創(chuàng)建的。如果你的工廠返回的是一個已經(jīng)存在的單例比如靜態(tài)實例容器可能會重復釋放同一個對象這時候要格外小心。經(jīng)驗是讓容器管理生命周期不要在工廠里返回自己管理生命周期的“外來對象”除非你確認不會出現(xiàn)重復釋放問題。7. 架構(gòu)層面的實踐接口、模塊化注冊與可測試性依賴注入的最終勝利不在于“會用”而在于“用得順手”。我自己在架構(gòu)層面有幾條心得分享給大家。7.1 每個項目都按模塊拆分注冊擴展方法我參與過的項目中最容易失控的是那個巨無霸Program.cs或Startup.cs。幾十個AddSomething()擠在一起誰也不敢動改一行都心驚膽戰(zhàn)。后來我養(yǎng)成了一個習慣每個業(yè)務(wù)模塊自己寫一個服務(wù)注冊擴展方法內(nèi)部只負責本模塊依賴的服務(wù)然后在Program.cs里調(diào)用它。舉個例子一個“訂單模塊”可以有一個public static class OrderServiceCollectionExtensions { public static IServiceCollection AddOrderModule(this IServiceCollection services) { services.AddScopedIOrderRepository, SqlOrderRepository(); services.AddScopedIOrderService, OrderService(); services.AddScopedIOrderDomainEventHandler, OrderDomainEventHandler(); return services; } }Program.cs里三五行就搞定builder.Services.AddInfrastructureModule(); builder.Services.AddOrderModule(); builder.Services.AddPaymentModule();這樣每個模塊的依賴關(guān)系集中在模塊自己的擴展方法里找問題的時候直接進模塊文件不用在啟動文件里撈針。配合上模塊化項目的層次結(jié)構(gòu)應(yīng)用層、領(lǐng)域?qū)?、基礎(chǔ)設(shè)施層、表現(xiàn)層每一層的 DI 注冊職責也能被清晰劃分。7.2 用容器做依賴注入但也別把一切都扔進容器有一類東西我不建議放容器里。比如配置對象直接用IOptionsT、靜態(tài)工具類如MathHelper、簡單的數(shù)據(jù)傳輸對象DTO。容器存在的意義是管理復雜依賴關(guān)系和生命周期如果什么東西都硬塞進容器解析鏈會越來越長性能下降排查也麻煩。還有一類需要小心的是“長期存在的服務(wù)”和“短期請求”混合的情況。比如 Singleton 的緩存服務(wù)里不小心引用了 Scoped 的DbContext這就是架構(gòu)層面的錯誤。我給出的建議很簡單畫一條依賴規(guī)則——Singleton 只能依賴 SingletonScoped 可以依賴 Scoped 和 SingletonTransient 可以依賴任意生命周期。寫進團隊規(guī)范當作評審時的關(guān)注點。7.3 依賴注入如何讓測試變得更簡單依賴注入最大的工程紅利是“可測試性”。因為一個類的依賴都是通過接口注進來的測試時你可以隨手替換成假的實現(xiàn)不需要啟動整個應(yīng)用不需要碰數(shù)據(jù)庫不需要真實發(fā)郵件。我寫單元測試時的做法是[Fact] public async Task GetWeatherAsync_WhenCityIsEmpty_ThrowsArgumentException() { var weatherService new WeatherService( Mock.OfIWeatherRepository(), Mock.OfICacheService()); await Assert.ThrowsAsyncArgumentException( () weatherService.GetWeatherAsync()); }這里每個依賴都能用 mock 對象替代測試用例短小明確。如果沒有依賴注入你可能要花大力氣構(gòu)造WeatherService的內(nèi)部依賴甚至要起一個完整的服務(wù)宿主測試效率和可維護性都差很多。7.4 依賴注入與模塊化邊界別讓容器變成“上帝對象”有一種反模式是為了讓某個服務(wù)在任何地方都能拿到把它注冊成 Singleton然后在幾乎每個類里注入它。這會造成隱式的全局依賴代碼之間通過這個“上帝對象”互相通信模塊邊界名存實亡。我在一些老項目里見過這種現(xiàn)象整改起來特別痛苦。正確的做法是依賴關(guān)系要顯式地通過構(gòu)造函數(shù)表達出來。如果一個類需要“當前用戶信息”不要讓它自己去全局容器里拿而是讓調(diào)用方把用戶信息顯式傳進來。容器只用來組裝那些“真正需要容器管理的服務(wù)”不要用它作為傳遞參數(shù)的通道。這一點做得好模塊邊界才能保持清晰。8. 那些坑循環(huán)依賴、作用域失控與我沒能早發(fā)現(xiàn)的錯誤最后一個大章節(jié)聊幾個實際項目中經(jīng)常踩的坑。這些坑每個我都見過或者親身體驗過希望你們能提前避雷。8.1 循環(huán)依賴兩個服務(wù)互相引用彼此依賴注入最經(jīng)典的報錯之一A依賴BB又依賴A。容器在嘗試解析時會發(fā)現(xiàn)依賴鏈成了一個環(huán)然后拋出異常。解決辦法一般有三種重構(gòu)拆分把 A 和 B 之間互相依賴的那部分邏輯抽出來放到第三個類 C 里A 和 B 都依賴 C循環(huán)自然解除。這是最徹底的方案也是我最推薦的方式。改變生命周期如果 A 和 B 都是 Transient改成其中一個為 Singleton 或 Scoped有時能繞過構(gòu)建循環(huán)的問題。但這治標不治本潛在風險仍然在。延遲解析某個服務(wù)在真正用到時才去容器解析通過注入IServiceProvider而不是在構(gòu)造函數(shù)里直接依賴。可以解決問題但代價是“依賴關(guān)系變隱式了”而且會破壞構(gòu)造函數(shù)注入的清晰性。我的經(jīng)驗是遇到循環(huán)依賴先停下來想想設(shè)計問題而不是急著找 hack。循環(huán)依賴通常意味著職責邊界劃分不當。重構(gòu)雖然工作量大一點但以后維護的舒適度完全值得。8.2 作用域失控一個 Scoped 服務(wù)被 Singleton 持有了這個坑我在生命周期章節(jié)提過但值得再具體演示一下。假設(shè)你有一個ICacheService注冊成了 Singleton而它內(nèi)部注入了IBillingRepositoryScoped。容器啟動時不會立刻檢測到錯誤除非開啟了ValidateOnBuild但等到某個請求使用了這個緩存服務(wù)運行時就會拋出異常。這類問題最陰險的地方是它不一定在啟動階段出現(xiàn)而是取決于哪個請求先觸發(fā)。A 客戶端的請求觸發(fā)了一切正常B 客戶端的請求觸發(fā)了直接 500。我見過一個項目因為這個原因偶發(fā)崩潰排查了好久才定位到這層關(guān)系。最好的防線就是我在前面說的同一個服務(wù)生命周期統(tǒng)一Singleton 依賴鏈上全部是 Singleton在開發(fā)環(huán)境開啟服務(wù)作用域驗證。這三條做到了這類坑基本能全部躲掉。8.3 過度注入構(gòu)造函數(shù)動不動就七八個參數(shù)如果一個服務(wù)類構(gòu)造函數(shù)里要注入七八個東西這個類八成違背了“單一職責原則”。七八個依賴意味著它同時在做好幾件事。我見過最夸張的某個服務(wù)構(gòu)造函數(shù)里塞了 12 個依賴每次修改都要傳新參數(shù)測試時 mock 也要寫 12 行。重構(gòu)思路是拆類把數(shù)據(jù)庫訪問拆出去、把通知拆出去、把緩存拆出去然后用門面模式或組合模式把幾個小服務(wù)組合起來。依賴注入容器擅長組裝所以“很多小對象組合成一個大對象”是合理的但“一個大對象硬吞進無數(shù)依賴”是不合理的。8.4 忘記釋放 scope 資源在手動創(chuàng)建 Scope 的場景里后臺任務(wù)、控制臺應(yīng)用如果忘記using釋放 ScopeScoped 服務(wù)里創(chuàng)建的DbContext、HTTP 客戶端連接等資源就會一直占著內(nèi)存時間長了可能引發(fā)連接池耗盡、內(nèi)存泄漏。我給自己定的習慣是所有手動創(chuàng)建的 Scope 一律用using或await using包起來確保離開代碼塊就釋放。哪怕只是解析一個不痛不癢的小服務(wù)也養(yǎng)成這個習慣免得哪天換成DbContext時踩雷。8.5 啟動時解析 Scoped 服務(wù)的“想當然”錯誤前面說過在Program.cs或Startup.cs里直接解析 Scoped 服務(wù)是個常見的坑。比如有人想在啟動時初始化 admin 用戶var adminService app.Services.GetRequiredServiceIAdminService(); adminService.Initialize();如果IAdminService注冊的是 Scoped這段代碼會直接報錯未開啟ValidateScopes時也可能不報錯但行為不保證。正確寫法using (var scope app.Services.CreateScope()) { var adminService scope.ServiceProvider.GetRequiredServiceIAdminService(); adminService.Initialize(); }這個“手動開 Scope 解析服務(wù)”的模式在 .NET 6 的WebApplication環(huán)境里尤其常見因為Program.cs里寫啟動邏輯的人很多。記住一條根容器的ApplicationServices是用來解析 Singleton 和通過工廠解析服務(wù)的不是給你解析 Scoped 服務(wù)的。9. 我的推薦實踐從開發(fā)到生產(chǎn)環(huán)境一路穩(wěn)最后我給出一份我在實際項目里會用的“依賴注入實踐清單”。這些條不是什么金科玉律但經(jīng)過多個項目的錘煉確實能幫我少踩很多坑。注冊入口盡量集中在模塊擴展方法里不要在Program.cs里散落大量注冊代碼。每個模塊對自己負責注冊代碼的查找成本極大降低。生命周期統(tǒng)一且顯式同一個服務(wù)類型只注冊一種生命周期。注冊 Unity 時團隊規(guī)范里寫明“所有服務(wù)必須顯式指定生命周期”不允許使用默認的自動注冊工具把一切都變成 Transient 或 Singleton。在開發(fā)環(huán)境和生產(chǎn)環(huán)境都開啟ValidateScopes。雖然生產(chǎn)環(huán)境有一些性能開銷但換來的是早期發(fā)現(xiàn)生命周期錯誤。如果對性能極度敏感可以在生產(chǎn)環(huán)境關(guān)閉但要保證測試和預發(fā)布環(huán)境開啟。堅持構(gòu)造函數(shù)注入避免屬性注入和服務(wù)定位器模式。構(gòu)造函數(shù)注入最顯式依賴關(guān)系一目了然。雖然屬性注入寫起來更少但“依賴關(guān)系隱式化”后代碼的可讀性和可測性會變差。使用IOptionsT來管理配置不要直接把配置對象注冊成 Singleton。這樣配置的刷新、熱更新才有標準支持測試時替換配置也更靈活。對資源型服務(wù)比如 DbContext、數(shù)據(jù)庫連接優(yōu)先使用 Scoped并且確保在請求管道或手動 Scope 里使用。如果需要在后臺任務(wù)里使用就手動創(chuàng)建并釋放 Scope。依賴方向只允許單向流動接口定義在一個模塊實現(xiàn)放在基礎(chǔ)設(shè)施層應(yīng)用層只依賴接口。這樣 Web API、后臺任務(wù)、測試都能共用同一個接口層模塊之間的耦合被降到最低。定期做依賴關(guān)系審計可以寫一個簡單的構(gòu)建腳本在 CI 階段把服務(wù)注冊列表輸出到日志里看看有沒有某個模塊的注冊依賴異常。這個對團隊協(xié)作特別有幫助。我可以坦誠地說依賴注入這套機制我自己從“會用”到“覺得香”經(jīng)歷了挺長時間。很多經(jīng)驗也是靠踩坑換來的——特別是那幾個生命周期相關(guān)的坑我至今記憶猶新。希望這篇長文能幫你把 ASP.NET Core 依賴注入從“知道概念”推向“理解本質(zhì)”以后在項目里用它建模、設(shè)計服務(wù)邊界、排查疑難問題的時候能更有底氣。