對於開發 .NET MAUI 的工程師來說，.NET 11 帶來了一個底層架構的重大轉折。從 .NET 11 Preview 4 開始，Android、iOS 與 Mac Catalyst 平台的預設執行環境（Runtime）將從長期以來使用的 Mono 遷移至 CoreCLR。
為了讓初入此領域的工程師理解這次變更的意義，我們需要先釐清什麼是 Runtime，以及為什麼這次遷移至關重要。
執行環境 Runtime 的背景知識
簡單來說，Runtime 是讓你的 C# 程式碼能在特定裝置上跑起來的基礎設施。它負責管理記憶體（GC）、將中間語言（IL）轉換為機器碼（JIT 編譯）以及處理執行時的錯誤。
在過去的十幾年裡，.NET 的世界被分成了兩半。伺服器端、雲端與桌面應用程式使用的是 CoreCLR（現代 .NET 的核心）；而行動端（iOS, Android）則依賴 Mono。Mono 是一個極其偉大的專案，它在 20 年前就讓 .NET 能在非 Windows 平台運行，是 Xamarin 與早期 MAUI 的功臣。
然而，這種分立導致了開發上的痛點：同樣的程式碼在伺服器端（CoreCLR）與手機端（Mono）可能會有不同的記憶體回收行為（GC）、不同的效能表現，且除錯工具並不統一。
為什麼要遷移到 CoreCLR
這次將 .NET MAUI 全面移至 CoreCLR，主要目標是達成 runtime 統一化，具體帶來以下三大實務好處。
第一，行為一致性。現在你的行動端 App 與後端 API 使用相同的執行環境。這意味著你不再需要擔心某個 Bug 只在手機端出現，而伺服器端卻正常，因為兩者的 JIT 編譯行為與記憶體管理邏輯現在是一致的。
第二，效能基礎的升級。CoreCLR 帶來了更強大的編譯技術，包括分層編譯（Tiered Compilation）、ReadyToRun（R2R，一種預編譯技術，能大幅縮短啟動時間）以及 PGO（Profile-Guided Optimization，根據實際運行數據優化程式碼）。對於使用者最在意的 App 啟動速度，這些技術能提供顯著的提升。
第三，邁向 NativeAOT。NativeAOT（原生提前編譯）能將程式碼直接編譯成原生機器碼，不需要在執行時進行 JIT 編譯，這能極大化地減少記憶體占用並提升啟動速度。CoreCLR 是 NativeAOT 的基礎，這次遷移為 Android 平台未來全面支援 NativeAOT 鋪平了道路。
實務上的影響與注意事項
雖然理論上 CoreCLR 更強大，但在實際遷移過程中，工程師必須注意以下幾點。
效能並非絕對提升。雖然基礎 App 的啟動速度明顯加快，但根據社群回饋，部分規模較大且複雜的 Android App 反而出現啟動時間增加或安裝包體積變大的情況。因此，切換到 .NET 11 後，請務必在實體裝置上測量冷啟動（Cold Start）與熱啟動（Warm Start）的時間，而非盲目相信更新。
除錯工具的同步。一個巨大的好處是，你現在可以在行動裝置上使用 dotnet-trace 與 dotnet-counters 等強大的診斷工具，這在 Mono 時代是非常困難的。
相容性風險。如果你使用了大量依賴反射（Reflection）、動態程式碼生成，或是某些 Mono 專屬的 API，請仔細測試功能是否正常。
排除的平台。為了專注於現代化架構，.NET 11 的 CoreCLR 將不再支援 Android x86、Android API 23 以下版本以及部分嵌入式 API。
如何處理遷移問題
如果在升級 .NET 11 後發現 App 出現嚴重的效能退化或崩潰，且無法在短時間內修復，你可以透過在專案檔（.csproj）中加入 UseMonoRuntime 標記來暫時切換回 Mono 執行環境。
這是一個過渡期的緩衝機制，讓開發者能確保產品發佈時的穩定性，同時將問題回報給微軟團隊。
總結
從 Mono 遷移到 CoreCLR 不是要否定 Mono 的貢獻，而是 .NET 生態系邁向完全統一的最後一步。對於工程師而言，這意味著更一致的開發體驗、更強大的效能優化手段以及更專業的診斷工具。建議所有 MAUI 開發者在 Preview 階段就開始進行 Release 模式的測試，確保 App 在新環境下依然穩健。
來源：devblogs.microsoft.com - .NET MAUI Moves to CoreCLR in .NET 11
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。