從 .NET Framework 到 .NET Core：一個必要的轉變
.NET Framework 和 .NET Core（現稱 .NET）不是競爭的替代品——它們代表不同世代的設計決策。.NET Framework 誕生於 2002 年，綁死在 Windows 上；.NET Core 從 2016 年起重新設計，跨平台、開源、模組化。微軟已明確宣告 .NET Framework 4.8.1 是最後一個主要版本，不再加入新功能，只做安全性修補。這個時間點對正在評估是否遷移的團隊來說是最實際的理由。
以下從四個面向說明差異。
跨平台
.NET Core 從設計之初就以跨平台為目標，同一份程式碼可以在 Windows、Linux 和 macOS 上建置與執行。這對想把工作負載搬上 Linux 容器或雲端的團隊影響最直接：容器基底映像可以選更精簡的 Linux 版本，不必帶著 Windows Server 授權費。
.NET Framework 本身只支援 Windows。Mono 是另一個獨立的開源 .NET 實作（最初由 Novell/Xamarin 開發，2016 年 Microsoft 收購 Xamarin 後納入管理），可以讓 C# 程式碼跑在 Linux 和 macOS 上，但它和 .NET Framework 是兩套分開的 runtime，API 相容程度並非百分之百，遇到 Windows-only API 仍然會踩坑。原生跨平台和「透過另一套 runtime 間接相容」是完全不同的事。
效能
.NET Core 歷代版本在效能上有系統性投入，從 JIT 編譯器（RyuJIT）、Span<T> 低配置 API，到 ASP.NET Core 的 HTTP pipeline 重寫，都有可量測的改進。TechEmpower Web Framework Benchmarks 的 plaintext 項目中，ASP.NET Core 長期排在各主流框架的前段，並不是行銷語言。
.NET Framework 的效能受限於當年的設計選擇，很多低層實作難以在不破壞向下相容的前提下替換，這也是微軟決定從頭重寫的根本原因之一。
部署
.NET Core 提供兩種主要部署模式：
- SCD（自包含部署）：把 runtime 和應用程式一起打包。目標機器不需要預裝 .NET，可以完全控制所用的 runtime 版本，代價是產出物較大。
- FDD（框架依賴部署）：只打包應用程式本身，目標機器必須預裝對應版本的 .NET runtime。產出物小，但環境必須先備妥。
值得注意的是：FDD 不是「不必擔心目標環境的 .NET 版本」——恰恰相反，FDD 高度依賴目標機器的 runtime 版本。只有 SCD 才能完全隔離環境差異。.NET 5 之後還加入了 Single-file publish（整個應用打成單一執行檔）和 ReadyToRun（預編譯降低冷啟動時間）等選項，可以視需求疊加使用。
.NET Framework 的部署綁在 Windows Update 和系統預裝的 .NET Framework 版本上，升版本時往往需要依賴作業系統的更新週期，彈性較低。
開發生態與後續維護
.NET Core 是 Microsoft 目前的主線開發平台，新版 C# 語言特性、新的 BCL API、效能改進都只在這條線上出現。.NET Framework 維持在 4.8.1，微軟的官方立場是：只做安全性修補，不加功能。
長期來看，留在 .NET Framework 等於接受技術凍結。套件生態也在往 .NET 5+ 傾斜，部分 NuGet 套件已停止發布支援 .NET Framework 的版本。
哪些應用遷移比較麻煩
並非所有 .NET Framework 應用都能順利搬過去。幾類典型的高難度情況：
- WCF 服務端：.NET 上沒有內建的 WCF 服務端實作。CoreWCF 是社群維護的替代方案，覆蓋率不完整。
- WebForms：架構差異太大，沒有對應的 .NET Core 版本，只能改寫。
- WinForms / WPF：.NET 5+ 起正式支援，但必須跑在 Windows 上，跨平台優勢在此情境不適用。
- COM Interop / Windows 特定 API：仍然可以跑，但有些行為和 .NET Framework 不完全一致。
評估遷移時，微軟的 .NET Upgrade Assistant 可以掃描現有專案、標出相容性問題，給出遷移難度的初步估計。工具本身不能全自動完成遷移，但可以省掉很多手動排查的時間。
新專案幾乎沒有理由選 .NET Framework。舊系統是否值得遷移，主要取決於是否踩到上面幾類高難度情況，以及維護成本和遷移成本的比較。
