在多年 .NET 生產(chǎn)環(huán)境實(shí)戰(zhàn)中，我發(fā)現(xiàn)一個規(guī)律：內(nèi)存問題往往藏在你最想不到的地方。

測試時一切正常，上線一周后，服務(wù)開始變慢、日志堆成山，最后大家齊刷刷甩鍋給垃圾回收器（GC）：“GC 太垃圾了！”

但真相往往是：問題不在 GC，而在我們的代碼寫法和資源管理習(xí)慣。

我們團(tuán)隊維護(hù)過幾十個不同業(yè)務(wù)的 .NET 應(yīng)用，幾乎每次排查內(nèi)存問題，都會看到同樣的錯誤反復(fù)上演。真正救我們的，從來不是什么“性能黑科技”，而是一些簡單、穩(wěn)定、可落地的工程習(xí)慣。

下面這 6 個 .NET 內(nèi)存優(yōu)化技巧，就是我們用血淚換來的經(jīng)驗，至今仍在生產(chǎn)環(huán)境里穩(wěn)穩(wěn)跑著。

1. LINQ 無處不在？那很可能是壞事

LINQ 確實(shí)讓代碼看起來優(yōu)雅又簡潔，但我們親眼見過它在高頻路徑上“優(yōu)雅地殺死性能”。

曾經(jīng)有個老 API，所有業(yè)務(wù)邏輯都套著 LINQ 查詢，讀起來很舒服。但每個 .Where()、.Select() 都在背后創(chuàng)建臨時迭代器、委托、匿名對象 —— 內(nèi)存分配蹭蹭漲。

后來我們把核心循環(huán)改成普通的 for 或 foreach，代碼是長了點(diǎn)，但**內(nèi)存占用直降 40%**，響應(yīng)延遲也明顯改善。

?? 老司機(jī)建議：LINQ 適合業(yè)務(wù)邏輯清晰、數(shù)據(jù)量小的場景；高頻、大數(shù)據(jù)、性能敏感路徑，請果斷用傳統(tǒng)循環(huán)。有時候，“無聊的代碼”才是“好代碼”。

2. 能重用的就別重建

這是最容易被忽視、但收益最大的優(yōu)化點(diǎn)。

幾年前我們搞了個報表生成器，每晚處理幾十 GB 的 CSV。代碼里為每個文件都 new StringBuilder()、new List<T>()，用完就扔。小數(shù)據(jù)時沒問題，數(shù)據(jù)一多，**內(nèi)存直接爆到 10GB+**。

后來我們改用 ArrayPool<T> 復(fù)用緩沖區(qū)，StringBuilder 也改成清空復(fù)用（Clear()），不再新建。結(jié)果：**內(nèi)存穩(wěn)定在 2GB，處理速度還快了 20%**。

?? 經(jīng)驗總結(jié)：對象創(chuàng)建有成本，尤其是大對象或高頻創(chuàng)建。能重用的，就別重建 —— 既省時間，也省內(nèi)存。

3. 記得釋放資源（Dispose），每一次都要！

如果你心里想著：“這個我待會兒再清理”——那你幾乎可以肯定：你永遠(yuǎn)不會清理。

任何實(shí)現(xiàn)了 IDisposable 的對象（比如文件流、數(shù)據(jù)庫連接、HttpClient），不用完就釋放，就是在埋雷。

我們曾有個后臺任務(wù)，上傳日志到 Azure Blob，開發(fā)者忘了 Dispose 文件流。程序跑了一周，內(nèi)存漲到 8GB，最后 OOM 崩潰。排查幾小時才發(fā)現(xiàn)：就缺那一行 using。

后來我們強(qiáng)制推行 using var，從此再沒出過類似問題。

?? 經(jīng)驗總結(jié)：using 或 using var 是防資源泄漏最簡單、最有效的方式，沒有之一。

4. 小心緩存（Cache）——緩存不是萬能藥

緩存聽起來很美好，直到你發(fā)現(xiàn)：你緩存了太多根本沒人用的數(shù)據(jù)。

有一次我們把整個用戶對象緩存起來，以為能省數(shù)據(jù)庫查詢。結(jié)果內(nèi)存翻倍，性能卻沒提升 —— 分析發(fā)現(xiàn)，90% 的緩存項只被訪問一次。

后來我們改成只緩存高頻復(fù)用的小結(jié)果（比如權(quán)限碼、配置值），內(nèi)存降了，速度反而快了。

?? 經(jīng)驗總結(jié)：緩存的目的是提速，不是占內(nèi)存。越精準(zhǔn)的緩存，收益越大；越“貪心”的緩存，坑越深。

5. 別猜，先用 Profiler 查一查

憑感覺找內(nèi)存泄漏？那是在浪費(fèi)生命。

有次系統(tǒng)內(nèi)存突然飆升，團(tuán)隊猜是 EF Core 或 JSON 序列化的問題。結(jié)果用 dotMemory 一抓，真相讓人哭笑不得：開發(fā)者在每個請求里都 new HttpClient()，導(dǎo)致上千個未關(guān)閉的 TCP 連接堆積。

改成 HttpClientFactory 后，問題秒解。

?? 經(jīng)驗總結(jié)：猜測毫無意義，Profiler 才是真相。dotMemory、PerfView、Visual Studio Profiler —— 選一個，用起來。

6. 避免在循環(huán)中發(fā)生裝箱（Boxing）

這個問題隱蔽，但在高吞吐場景下殺傷力極強(qiáng)。

裝箱（Boxing） 是指把值類型（如 int、DateTime）當(dāng)成 object 使用時，自動轉(zhuǎn)成引用類型?？雌饋頍o害，但在循環(huán)里頻繁發(fā)生，會大量分配臨時對象，拖垮 GC。

我們有個服務(wù)每天處理百萬級消息，性能一直上不去。最后發(fā)現(xiàn)是日志框架里一句 logger.Info("ID: {0}", id) —— id 是 int，但日志方法參數(shù)是 object，每條日志都裝箱一次！

改成強(qiáng)類型日志（如 logger.Info("ID: {Id}", id)）后，**內(nèi)存分配減少 60%**，吞吐量直接翻倍。

?? 經(jīng)驗總結(jié)：在高頻路徑、日志、泛型集合中，警惕隱式裝箱。它不報錯，卻能悄悄拖垮你的服務(wù)。

結(jié)語

大多數(shù) .NET 內(nèi)存問題，根源不在框架，而在我們的編程習(xí)慣。

這 6 個技巧看似簡單，卻經(jīng)得起生產(chǎn)環(huán)境考驗： 別濫用 LINQ；能重用就別重建；用 using 釋放資源；緩存要精準(zhǔn)；先 Profile 再優(yōu)化 ；警惕裝箱  。

我們團(tuán)隊親眼見證過：幾個小改動，就能讓一個瀕臨崩潰的服務(wù)重回穩(wěn)定。

如果你的 .NET 應(yīng)用在高負(fù)載下開始卡頓、內(nèi)存飆升，也許不是該加機(jī)器，而是該回頭看看這些“老習(xí)慣”。