在多年 .NET 生產環境實戰中，我發現一個規律：內存問題往往藏在你最想不到的地方。

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

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

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

下面這 6 個 .NET 內存優化技巧，就是我們用血淚換來的經驗，至今仍在生產環境里穩穩跑著。

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

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

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

后來我們把核心循環改成普通的 for 或 foreach，代碼是長了點，但**內存占用直降 40%**，響應延遲也明顯改善。

?? 老司機建議：LINQ 適合業務邏輯清晰、數據量小的場景；高頻、大數據、性能敏感路徑，請果斷用傳統循環。有時候，“無聊的代碼”才是“好代碼”。

2. 能重用的就別重建

這是最容易被忽視、但收益最大的優化點。

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

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

?? 經驗總結：對象創建有成本，尤其是大對象或高頻創建。能重用的，就別重建 —— 既省時間，也省內存。

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

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

任何實現了 IDisposable 的對象（比如文件流、數據庫連接、HttpClient），不用完就釋放，就是在埋雷。

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

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

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

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

緩存聽起來很美好，直到你發現：你緩存了太多根本沒人用的數據。

有一次我們把整個用戶對象緩存起來，以為能省數據庫查詢。結果內存翻倍，性能卻沒提升 —— 分析發現，90% 的緩存項只被訪問一次。

后來我們改成只緩存高頻復用的小結果（比如權限碼、配置值），內存降了，速度反而快了。

?? 經驗總結：緩存的目的是提速，不是占內存。越精準的緩存，收益越大；越“貪心”的緩存，坑越深。

5. 別猜，先用 Profiler 查一查

憑感覺找內存泄漏？那是在浪費生命。

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

改成 HttpClientFactory 后，問題秒解。

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

6. 避免在循環中發生裝箱（Boxing）

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

裝箱（Boxing） 是指把值類型（如 int、DateTime）當成 object 使用時，自動轉成引用類型。看起來無害，但在循環里頻繁發生，會大量分配臨時對象，拖垮 GC。

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

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

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

結語

大多數 .NET 內存問題，根源不在框架，而在我們的編程習慣。

這 6 個技巧看似簡單，卻經得起生產環境考驗： 別濫用 LINQ；能重用就別重建；用 using 釋放資源；緩存要精準；先 Profile 再優化 ；警惕裝箱  。

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

如果你的 .NET 應用在高負載下開始卡頓、內存飆升，也許不是該加機器，而是該回頭看看這些“老習慣”。