今天的新开发者第一次接触 .NET，很容易被名字绕晕：.NET Framework、.NET Core、.NET Standard、.NET 5、6、7、8、9、10，以及正在路上的后续版本。它们到底是一套东西，还是很多套东西？
Bipin Joshi 这篇文章的有意思之处，在于它没有把这些名字当成版本对照表来讲，而是把它看作一段平台身份重建史。.NET 今天的命名不是单纯的营销混乱，而是一个平台从旧假设里挣脱、公开重建、桥接碎片、最后统一起来的痕迹。
Windows 时代
.NET Framework 1.0 在 2002 年发布。它背后的默认世界观很清楚：Windows 就是平台。
这在当时不是荒唐假设。企业软件运行在 Windows Server 上，开发工具是 Visual Studio，数据库常常是 SQL Server，桌面应用有 WinForms 和后来的 WPF，Web 应用有 ASP.NET。对很多开发者来说，.NET Framework 是从 COM、DCOM、Win32 混乱里走出来后的秩序感。
它给了开发者托管运行时、垃圾回收、庞大的标准库、统一的开发体验。只要你的目标是 Windows 生态，它几乎就是那个时代最完整的企业开发平台。
问题不在于它当时错了。问题在于世界变化得太快。
Linux 服务器加速普及，Docker 改变部署方式，云更喜欢轻量、可移植的进程，开源从边缘文化变成互联网基础设施。与此同时，.NET Framework 深度绑定 Windows：System.Drawing 依赖 GDI+，ASP.NET 和 IIS 关系紧密，很多 API 都带着 Windows 时代的假设。
它的成功，反过来成了它最难移动的原因。
必须重建
到 2010 年代初，Microsoft 面临一个很多长期系统都会遇到的问题：继续修补，还是重新开始。
继续修补可以保留连续性，但会积累越来越多债务。重新开始则意味着承认旧基础不适合未来，还要冒着让老用户失望的风险。
.NET Core 就是在这个背景下出现的。Microsoft 不只是做了一个新运行时，还把它开源到 GitHub 上。这对当时的 Microsoft 来说，是一个很大的姿态变化：把过去高度专有的平台核心拿出来，让社区一起参与。
但重建从来不轻松。
.NET Core 1.0 在 2016 年发布，速度快、跨平台、可以跑在 Linux、macOS、Docker、ARM 上，也可以 self-contained 部署。但它缺少很多 .NET Framework 开发者熟悉的东西：没有 Web Forms，没有完整 WCF，没有 AppDomain，很多 API 不在原来的位置，甚至不再存在。
对老开发者来说，这不是“升级一下”那么简单。它像是让一个专家重新变成初学者。文章里把这种感受写得很准确：不是你的旧工作错了，而是世界改变了。
Standard 是桥
有几年，.NET 世界同时存在两个主要现实：.NET Framework 4.x 继续支撑大量企业系统，.NET Core 作为新方向快速成长。
库作者最痛苦。一个 NuGet 包到底 target .NET Framework，还是 .NET Core？如果只支持一边，另一边用不了；如果 multi-target，就要维护多套配置，还要小心避开某些平台没有的 API。
.NET Standard 就是在这个碎片阶段出现的。它不是一个运行时，也不是另一个“新版 .NET”，而是一份 API 规范：只要某个运行时实现了这份标准，针对它写的库就能被消费。
所以 .NET Standard 更像和平条约，不是永久宪法。它的价值在于桥接 Framework 和 Core 之间的裂缝，让生态有时间过渡。
这也解释了为什么今天的新项目不应该把 .NET Standard 当成默认目标。它曾经重要，但它的历史任务已经基本完成。建筑已经立起来，脚手架不再是中心。
去掉 Core
2020 年，Microsoft 发布 .NET 5。名字不是 .NET Core 4，也不是 .NET Framework 5，而是简单的 .NET 5。
这个命名动作很关键。
去掉 Core，不只是为了简化名称，而是在宣布：分裂时代结束了。Framework 和 Core 不再是两个未来方向；现代 .NET 接过了这个名字。
版本号从 3.1 跳到 5，也是在刻意避开 .NET Framework 4.x 的混淆。它告诉开发者：这不是 Framework 的小版本更新，而是统一后的新平台。
对今天的初学者来说，最重要的判断可以很简单：如果你看到 2018 年左右的教程写 “.NET Core”，很多时候它指的就是今天的现代 .NET 前身；如果你看到旧文章建议 target .NET Standard，要先判断那是不是为当年的过渡期服务。
现在的主线是 .NET，后面跟版本号。
成熟阶段
.NET 6 到 .NET 10 这几年，平台的叙事从“我能不能活下来”变成了“我还能持续变好”。
.NET 6 带来 minimal APIs、hot reload、MAUI 等方向，也让 Blazor 更清晰地进入现代 .NET 的版图。Blazor 的意义不只是“C# 写前端”，而是 .NET 终于能用自己的语言和工具进入浏览器交互应用领域。
.NET 7 继续推动性能，涉及 JSON、LINQ、正则、Native AOT 等方向。.NET 8 作为 LTS 版本，给很多生产团队一个更稳定的落点。.NET 9 和 .NET 10 延续 annual release cadence，平台不再每年重新定义自己，而是在清晰身份上继续演进。
文章里有一句判断很耐看：成熟的平台不一定像新平台那样刺激，它的价值在于可靠。API 经常刚好在你需要的位置，错误信息更好懂，性能比你预期更稳，工具链不再让人担心底座会变。
这就是成熟。
.NET 11 的意义
文章写于 2026 年 6 月，提到 .NET 11 已经在前方。这个数字本身也很有意思。
在 Framework 时代，版本号往往意味着很大的平台事件。现在 .NET 的年度发布更像持续生长：运行时更快，编译器更聪明，AOT 更成熟，云原生和跨平台能力继续增强。版本号继续增加，不是因为平台还在寻找身份，而是因为一个活的平台会继续成长。
对后来者来说，“我是不是已经落后十个版本了”不是一个好问题。今天开始学 .NET，反而站在更稳的地面上：文档成熟，社区大，CLI、Visual Studio、VS Code、Rider 都很强，过渡期的很多混乱已经被前人消化掉了。
晚到稳定平台，不一定是劣势。你继承了别人穿越混乱后留下的成果。
真正的教训
这段历史不只是 .NET 的技术路线复盘，也像一个长期系统如何自我更新的案例。
.NET Framework 成功得太完整，以至于它和那个时代的假设绑定太深。Microsoft 后来做对的，不只是写了新 runtime，而是承认旧基础不适合未来，并愿意公开重建。
这需要一种组织层面的谦逊。不是继续给旧系统打补丁，也不是假装一切都没变，而是承认“我们要从这里重新开始”。开源、跨平台、社区协作，都是这次重建赢回信任的方式。
所以，当新开发者问为什么有这么多 .NET 名字时，可以这样解释：
.NET Framework 是 Windows 企业时代的正确答案。
.NET Core 是世界变化后的痛苦重建。
.NET Standard 是两个时代之间的桥。
.NET 5+ 是统一后的现代平台。
今天我们构建在 .NET 上，不是因为这段历史从未混乱过，而是因为它经历了混乱，并从里面走出来了。
如果你关注 AI 助手、开发工具和软件工程实践，可以关注 Aide Hub。这里会继续分享能落地的工具教程、技术观察和项目经验。