.NET Framework, .NET Core, 与 .NET

如果你是一名 .NET 开发者，大概率被这几个名字搞晕过：.NET Framework、.NET Core、.NET 5、.NET 6……再到最新的 .NET 10。它们之间到底是什么关系？是不是同一个东西改了个名字？今天厘清一下三者的历史和区别。

一、.NET Framework：Windows 时代的王者（2002 - 2019）

诞生背景：2002 年，微软为了对抗 Java 的“一次编写，到处运行”（Write Once, Run Anywhere），推出了 .NET Framework 1.0。这是第一代 .NET 平台，专为 Windows 设计。它的核心特点是：

• 只能跑在 Windows 上，深度绑定 Windows API。功能极其庞大，生态繁荣：Windows Forms、WPF（用于桌面开发）、ASP.NET Web Forms/MVC（用于网页开发）和 WCF（用于企业级通信）成为了一个时代的标准。
• 闭源起步，虽然后来部分开源，但整体开发主要由微软内部推动。
• 版本迭代到 4.8（2019 年发布）后就基本停止了大版本更新——4.8 是最后一个主版本，微软明确表示不会再有 .NET Framework 5。
• 至今仍然内置在 Windows 系统中，大量遗留的企业级应用(如 ASP.NET WebForms、WCF、传统 WinForms 桌面程序）仍跑在它上面。

可以把它理解成"过去时"——不是被淘汰,而是进入了"维护模式":只打安全补丁,不再增加新特性。

二、.NET Core：一次彻底的重生（2016 - 2020）

诞生背景：到了 2014 年前后，微软意识到 .NET Framework 的封闭和臃肿已经跟不上云原生、跨平台、Docker 容器化的时代趋势，于是启动了一个几乎是"推倒重来"的项目——.NET Core。它的核心特点是：

• 2016 年，.NET Core 1.0 正式发布，第一次实现了 跨平台（Windows / Linux / macOS）。
• 完全开源，代码托管在 GitHub，社区可以直接参与开发。
• 采用模块化、轻量化设计，摒弃了 Windows 系统的强绑定，采用模块化设计（通过 NuGet 按需引入包）。性能大幅提升，特别适合微服务和容器（Docker）部署。
• 高性能：从底层重构了编译器和运行时（CoreCLR），性能相比旧版 Framework 呈指数级提升。
• 经历了 1.0 → 1.1 → 2.0 → 2.1 → 2.2 → 3.0 → 3.1 的迭代，3.1（2019年）是一个长期支持版本（LTS），也是这条产品线最成熟的收官之作。

.NET Core 的出现标志着微软战略的重大转向：从"Windows 专属"走向"云原生、开源、跨平台"。

三、统一的 .NET：从 .NET 5 开始（2020 - 现在）

诞生背景：既然 .NET Core 已经足够成熟，且成为了未来的方向，2020 年，微软决定结束“双轨并行”的混乱局面，不再区分 .NET Framework 和 .NET Core， 两条线合并为一条,统一命名为 .NET。

有意思的是，版本号直接跳过了"4"——没有".NET 4"，是为了避免和 .NET Framework 4.x 混淆，直接从 .NET 5 开始。此后按照每年 11 月发布一个大版本的节奏推进：

版本	发布时间	类型
.NET 5	2020年11月	常规版本(18个月支持)
.NET 6	2021年11月	LTS(长期支持,3年)
.NET 7	2022年11月	常规版本
.NET 8	2023年11月	LTS
.NET 9	2024年11月	常规版本
.NET 10	2025年11月	LTS(当前最新长期支持版)
.NET 11	预览中	尚未正式发布

也就是说，目前生产环境推荐使用的最新稳定版本是 .NET 10，它是一个 LTS 版本，官方会提供三年的长期支持，安全性和稳定性都有保障；.NET 11 目前还只有预览版，追新的开发者可以尝鲜，但不建议用在生产环境。

统一后的 .NET 融合了 .NET Core 的跨平台、高性能、开源基因，同时也吸收了 .NET Framework 生态中的一些成熟组件（比如 WPF、WinForms 也被移植了过来，可以在新 .NET 上跑 Windows 桌面程序），并整合了 Mono/Xamarin。实现了对移动端（iOS/Android）、桌面端、Web Assembly（Blazor）的全平台支持。

四、三者到底有什么区别？

维度	.NET Framework	.NET Core	现代 .NET(5及以后)
平台	仅 Windows	跨平台	跨平台
开源	部分开源	完全开源	完全开源
性能	一般	大幅提升	持续优化,性能最强
更新状态	停止大版本更新(4.8封版)	已被现代.NET取代	活跃开发中
部署方式	传统IIS/Windows服务	支持容器化部署	云原生、容器友好、支持AOT编译
典型技术栈	WinForms, WPF, ASP.NET (Web Forms/MVC), WCF	WPF/WinForms (仅限Windows), ASP.NET Core	MAUI (跨平台UI), Avalonia, ASP.NET Core, Blazor, Minimal APIs, gRPC

核心差异深剖：

1. 部署的灵活性（Xcopy Deployment）：
   • 在 .NET Framework 中，如果目标机器没有安装对应版本的 Runtime（比如 .NET 4.5），程序就无法运行。
   • 在 现代 .NET 中，你可以选择“独立部署（Self-contained）”，将运行时、依赖库和你的程序打包成一个单一的可执行文件（甚至是单文件）。目标服务器无需安装任何 .NET 环境，直接双击或通过命令行即可运行，非常适合 Docker 容器。
2. Native AOT（提前编译）：
   • 现代 .NET（自 .NET 7/8 起） 提供了强大的 Native AOT 支持。它不通过 JIT（即时编译器）在运行时将 IL 编译成机器码，而是在构建时直接编译成平台原生的二进制机器码。
   • 好处：零启动延迟、极低的内存占用、无需携带 JIT 编译器，包体积大幅减小，是无服务器计算（Serverless）和微服务部署的终极武器。而这是旧版 Framework 望尘莫及的。

简单一句话总结： .NET Framework 是过去，.NET Core 是转型期的产物，而现代 .NET(5/6/7/8/9/10)才是现在和未来。

五、各自适合什么场景?

.NET Framework 适用场景:

• 维护老旧的企业内部系统(尤其依赖 WCF、WebForms 的项目)
• 强依赖某些仅在 Windows Framework 生态下才有的第三方库
• 迁移成本极高、暂时没有重构计划的存量系统

.NET Core(如果你还在用旧项目)适用场景:

• 处于从 .NET Framework 向现代 .NET 迁移过渡阶段的项目

• 使用 .NET Core 3.1 LTS 版本、暂未升级的稳定生产系统

  行动建议：由于 .NET Core 3.1 到 .NET 6/8 的迁移门槛极低，建议尽快升级到最新的 LTS 版本（如 .NET 8），以获取安全补丁和显著的性能红利。

现代 .NET(推荐 .NET 10 LTS)适用场景:

• 全新项目的首选,无论是 Web API、微服务、桌面应用(WPF/WinForms/MAUI)还是云函数
• 需要跨平台部署Web 与微服务：使用 ASP.NET Core 配合Linux 容器、Docker 和 Kubernetes。其超高的吞吐量和极低的内存占用，能为企业节省大量的云资源成本。
• 云原生与 Serverless：利用 .NET 8/9 的 Native AOT，开发极速启动的 Web API 或后台服务。
• 跨平台桌面应用：
  • 使用 .NET MAUI 编写一套代码，同时运行在 Windows、macOS、iOS 和 Android 上。
  • 或者使用优秀的开源社区框架 Avalonia UI 进行高度定制化的跨平台桌面开发。
• 高性能要求的服务端应用,比如高并发的 ASP.NET Core Web API
• 现代 Web 前端：使用 Blazor，允许 C# 开发者无需编写 JavaScript，直接在浏览器端（通过 WebAssembly）构建富交互式的 Web 界面。
• AI 与机器学习：结合微软最新的 Microsoft.Extensions.AI 库，.NET 9 对集成大语言模型（LLM）、向量数据库以及 RAG 架构提供了原生且优雅的支持。

六、给开发者的建议

1. 新项目:无脑上现代 .NET,目前是 .NET 10 LTS,长期支持稳定可靠。
2. 老项目维护:如果是 .NET Framework 项目且短期没有重构计划,继续维护即可,微软仍会提供安全补丁;但如果有精力,建议规划向现代 .NET 迁移,官方也提供了 .NET Upgrade Assistant 等迁移工具。
3. 版本选择原则:生产环境优先选 LTS(偶数版本,如6、8、10),追新特性可以在测试环境尝试奇数版本或预览版,但不建议直接上生产。

---

.NET 的这段发展史,本质上是微软从"封闭的 Windows 生态"走向"开放的云原生时代"的缩影。理解这段历史,不仅能帮你选对技术栈,也能更好地理解微软这些年在开发者工具上的战略布局。