.NET Standard和.NET Core区别?
.NET Standard 和 .NET Core 就像是两种不同层面的设计理念，它们之间并非简单的取舍关系，而是相互关联、共同演进的。理解它们的区别，需要从“目标”和“实现”这两个维度去剖析。
.NET Standard：一块通用的“规范石碑”
你可以将 .NET Standard 想象成一块立在 .NET 生态系统中间的、非常重要的“规范石碑”。它的核心目标是什么？是“兼容性”和“共享性”。在 .NET 家族日益壮大的时候，我们有了 .NET Framework（传统的、Windows 独占的）、Xamarin（移动开发）、UWP（Windows 应用）、以及后来出现的 .NET Core（跨平台、高性能）。如果每个平台都各自为政，开发者在编写库的时候，就得为每个平台写一套完全相同的代码，这无疑是巨大的重复劳动和维护噩梦。
.NET Standard 的出现，就是为了解决这个问题。它定义了一套抽象的 API 集合。你可以把它理解成一个“契约”，一个关于“如果你想被认定为符合 .NET Standard 的某个版本，你就必须提供这些 API”的约定。它本身不是一个可以执行的代码，更不是一个运行时环境。它是一个兼容性标准，一个“蓝图”。
想象一下，你想制作一套积木，这套积木需要能在不同品牌的积木盒子里都能玩。.NET Standard 就像是给这套积木定了一个统一的接口标准，比如“所有积木块的底部必须有 4 个凸起，顶部必须有 4 个凹槽”。只要你的积木符合这个标准，无论你用的是乐高积木盒、得宝积木盒，还是其他什么牌子的盒子，理论上都能兼容。
.NET Standard 的版本号（比如 .NET Standard 2.0, 2.1）就代表了这块“石碑”上刻画的 API 集合的大小和范围。版本越高，包含的 API 越多，也就意味着它能被越多的 .NET 实现所支持。
.NET Core：一块坚实的“执行砖块”
而 .NET Core，则是一块实实在在、可以让你搭建应用的“执行砖块”。它是一个完整的、开源的、跨平台的 .NET 实现。它不仅仅是实现了 .NET Standard 定义的 API，它还是一个运行时，一个SDK，一个编译器，一个包管理器（NuGet）。
.NET Core 的设计目标是“高性能”、“跨平台”和“模块化”。它从头开始设计，摆脱了 .NET Framework 历史包袱，更加轻量、高效，并且可以在 Windows、macOS 和 Linux 上运行。
回到积木的比喻，.NET Core 就像是某个特定品牌的积木盒，它不仅按照那个通用的接口标准（.NET Standard）生产了自己的积木，它本身也是一个完整的、可以让你开始玩积木的“场景”。你可以用 .NET Core 来编写应用、开发 Web 服务、制作命令行工具等等。
它们的关系：兼容与实现
那么，.NET Standard 和 .NET Core 之间到底是什么关系呢？
.NET Core 实现 .NET Standard： 每一版本的 .NET Core，都支持一个或多个版本的 .NET Standard。这意味着，如果一个类库是为 .NET Standard 2.0 编写的，那么任何一个支持 .NET Standard 2.0 的 .NET 实现，包括 .NET Core，都可以直接使用这个类库。这就像是，你的按照通用接口标准的积木，可以放进乐高积木盒里玩一样。
.NET Standard 是 .NET Core 的“上层”： .NET Standard 定义了“应该有什么”，而 .NET Core 提供了“如何实现”。你可以认为 .NET Standard 是 .NET Core 需要遵循的“规则手册”。
.NET Core 提供了更底层的能力： .NET Core 除了实现 .NET Standard 提供的 API 外，还可能包含一些 .NET Standard 没有覆盖到的、更底层的、更现代的或者更针对特定平台的能力。例如，.NET Core 3.0 引入了对 WPF 和 Windows Forms 的支持，这些是特定于 Windows 的 UI 框架，并不在 .NET Standard 的设计范畴内（因为 .NET Standard 要追求最大化兼容）。
一个比喻：酒店的“星级标准”与“实体酒店”
你可以把 .NET Standard 想象成酒店的“星级评定标准”。比如，三星级酒店必须有空调、独立卫浴、24小时前台等等。这个标准本身不提供住宿，它只是一个评估体系。
.NET Core 就像是某个连锁酒店集团（比如希尔顿、万豪），它旗下的每一家酒店（.NET Core 的不同版本）都努力去达到并超越这个“星级标准”。一家三星级酒店（.NET Core 3.1）可能完全符合 .NET Standard 2.0 的要求，并且提供三星级酒店该有的一切服务。而一家四星级酒店（.NET 6）可能不仅符合 .NET Standard 2.1 的要求，还额外提供了健身房、室内游泳池等“非必需但更好”的服务。
总结一下：
.NET Standard 是一个抽象的 API 规范，它定义了一个版本的 .NET 实现应该包含哪些 API，目的是为了实现跨 .NET 实现的代码共享。
.NET Core 是一个完整的、开源的、跨平台的 .NET 实现，它本身包含运行时、SDK、编译器等，可以用来开发各种类型的应用程序。
.NET Core 的不同版本会支持不同版本的 .NET Standard，这意味着 .NET Core 可以运行那些为 .NET Standard 编写的类库。
从 .NET 5 开始，微软对 .NET 的命名和架构做了统一。“.NET 5”及后续版本（.NET 6, .NET 7, .NET 8 等）是 .NET Core 的演进，它们统一了 .NET Core、Xamarin 和 UWP 的能力，并继续保持跨平台和高性能的优势。所以，现在我们谈论的是“统一的 .NET”，而 .NET Core 是这个统一 .NET 的重要前身和基础。而 .NET Standard 作为一个跨平台兼容性的解决方案，其历史使命也逐渐被统一的 .NET 所取代，但它在过去扮演的角色是无可替代的。
.NET Standard：一块通用的“规范石碑”
你可以将 .NET Standard 想象成一块立在 .NET 生态系统中间的、非常重要的“规范石碑”。它的核心目标是什么？是“兼容性”和“共享性”。在 .NET 家族日益壮大的时候，我们有了 .NET Framework（传统的、Windows 独占的）、Xamarin（移动开发）、UWP（Windows 应用）、以及后来出现的 .NET Core（跨平台、高性能）。如果每个平台都各自为政，开发者在编写库的时候，就得为每个平台写一套完全相同的代码，这无疑是巨大的重复劳动和维护噩梦。
.NET Standard 的出现，就是为了解决这个问题。它定义了一套抽象的 API 集合。你可以把它理解成一个“契约”，一个关于“如果你想被认定为符合 .NET Standard 的某个版本，你就必须提供这些 API”的约定。它本身不是一个可以执行的代码，更不是一个运行时环境。它是一个兼容性标准，一个“蓝图”。
想象一下，你想制作一套积木，这套积木需要能在不同品牌的积木盒子里都能玩。.NET Standard 就像是给这套积木定了一个统一的接口标准，比如“所有积木块的底部必须有 4 个凸起，顶部必须有 4 个凹槽”。只要你的积木符合这个标准，无论你用的是乐高积木盒、得宝积木盒，还是其他什么牌子的盒子，理论上都能兼容。
.NET Standard 的版本号（比如 .NET Standard 2.0, 2.1）就代表了这块“石碑”上刻画的 API 集合的大小和范围。版本越高，包含的 API 越多，也就意味着它能被越多的 .NET 实现所支持。
.NET Core：一块坚实的“执行砖块”
而 .NET Core，则是一块实实在在、可以让你搭建应用的“执行砖块”。它是一个完整的、开源的、跨平台的 .NET 实现。它不仅仅是实现了 .NET Standard 定义的 API，它还是一个运行时，一个SDK，一个编译器，一个包管理器（NuGet）。
.NET Core 的设计目标是“高性能”、“跨平台”和“模块化”。它从头开始设计，摆脱了 .NET Framework 历史包袱，更加轻量、高效，并且可以在 Windows、macOS 和 Linux 上运行。
回到积木的比喻，.NET Core 就像是某个特定品牌的积木盒，它不仅按照那个通用的接口标准（.NET Standard）生产了自己的积木，它本身也是一个完整的、可以让你开始玩积木的“场景”。你可以用 .NET Core 来编写应用、开发 Web 服务、制作命令行工具等等。
它们的关系：兼容与实现
那么，.NET Standard 和 .NET Core 之间到底是什么关系呢？
.NET Core 实现 .NET Standard： 每一版本的 .NET Core，都支持一个或多个版本的 .NET Standard。这意味着，如果一个类库是为 .NET Standard 2.0 编写的，那么任何一个支持 .NET Standard 2.0 的 .NET 实现，包括 .NET Core，都可以直接使用这个类库。这就像是，你的按照通用接口标准的积木，可以放进乐高积木盒里玩一样。
.NET Standard 是 .NET Core 的“上层”： .NET Standard 定义了“应该有什么”，而 .NET Core 提供了“如何实现”。你可以认为 .NET Standard 是 .NET Core 需要遵循的“规则手册”。
.NET Core 提供了更底层的能力： .NET Core 除了实现 .NET Standard 提供的 API 外，还可能包含一些 .NET Standard 没有覆盖到的、更底层的、更现代的或者更针对特定平台的能力。例如，.NET Core 3.0 引入了对 WPF 和 Windows Forms 的支持，这些是特定于 Windows 的 UI 框架，并不在 .NET Standard 的设计范畴内（因为 .NET Standard 要追求最大化兼容）。
一个比喻：酒店的“星级标准”与“实体酒店”
你可以把 .NET Standard 想象成酒店的“星级评定标准”。比如，三星级酒店必须有空调、独立卫浴、24小时前台等等。这个标准本身不提供住宿，它只是一个评估体系。
.NET Core 就像是某个连锁酒店集团（比如希尔顿、万豪），它旗下的每一家酒店（.NET Core 的不同版本）都努力去达到并超越这个“星级标准”。一家三星级酒店（.NET Core 3.1）可能完全符合 .NET Standard 2.0 的要求，并且提供三星级酒店该有的一切服务。而一家四星级酒店（.NET 6）可能不仅符合 .NET Standard 2.1 的要求，还额外提供了健身房、室内游泳池等“非必需但更好”的服务。
总结一下：
.NET Standard 是一个抽象的 API 规范，它定义了一个版本的 .NET 实现应该包含哪些 API，目的是为了实现跨 .NET 实现的代码共享。
.NET Core 是一个完整的、开源的、跨平台的 .NET 实现，它本身包含运行时、SDK、编译器等，可以用来开发各种类型的应用程序。
.NET Core 的不同版本会支持不同版本的 .NET Standard，这意味着 .NET Core 可以运行那些为 .NET Standard 编写的类库。
从 .NET 5 开始，微软对 .NET 的命名和架构做了统一。“.NET 5”及后续版本（.NET 6, .NET 7, .NET 8 等）是 .NET Core 的演进，它们统一了 .NET Core、Xamarin 和 UWP 的能力，并继续保持跨平台和高性能的优势。所以，现在我们谈论的是“统一的 .NET”，而 .NET Core 是这个统一 .NET 的重要前身和基础。而 .NET Standard 作为一个跨平台兼容性的解决方案，其历史使命也逐渐被统一的 .NET 所取代，但它在过去扮演的角色是无可替代的。
网友意见
最开始 .NET Framework 只支持 Windows，而 mono 是一个社区的跨平台实现，后来出了个 .NET Core 跨平台了，但是由于 .NET Core 和 mono、.NET Framework 是不同的，虽然 mono 能跑大部分的 .NET Framework 程序集，但是 .NET Core 不行；而 mono 也不能跑 .NET Core 的程序集，.NET Core 也不能跑 mono 和 .NET Framework 的程序集。
由于 .NET 对库函数的引用类似动态链接库，程序集内并不包含库函数的实现，只包含库函数的签名，然后运行的时候才去加载对应的有实现的程序集完成“链接”过程最后调用，于是 .NET Standard 就应运而生了。
.NET Standard 参考三个实现的情况，划定了一组 API 的子集，这组 API 在 .NET Framework、mono 和 .NET Core 上都有实现，然后使 .NET Framework、mono 和 .NET Core 都能加载 .NET Standard 程序集，这样当用户调用 .NET Standard 里的 API 的时候，会把调用转发到当前运行时的基础库的实现上。
这样一来，只要用户的代码基于 .NET Standard 编写，就能同时在 .NET Framework、mono、.NET Core 上跑了。
而如果要使用各自平台独有的 API 的话，则不能基于 .NET Standard 来编写代码，而需要基于 .NET Framework、.NET Core 或者 mono 来编写代码。
后来到了 .NET Standard 2.1 的时候，由于 .NET Framework 掉了队，不再新增新的功能，于是 .NET Standard 2.1 干脆不支持 .NET Framework 了，只支持 mono 和 .NET Core。
再后来 mono 和 .NET Core 完成了基础库的统一，变成了新的 .NET，于是 .NET Standard 的使命也结束了，只剩下一个统一的 .NET。
类似的话题
-
.NET Standard 和 .NET Core 就像是两种不同层面的设计理念，它们之间并非简单的取舍关系，而是相互关联、共同演进的。理解它们的区别，需要从“目标”和“实现”这两个维度去剖析。.NET Standard：一块通用的“规范石碑”你可以将 .NET Standard 想象成一块立在 .............. -
在.NET中编写异步Web API可以带来显著的好处，尤其是在处理高并发、I/O密集型操作以及提升用户体验方面。下面我将详细阐述这些好处： 1. 提升吞吐量和响应能力 (Increased Throughput and Responsiveness)这是异步Web API最核心的好处。 并行处理.............
-
.NET 6 的泛型数学新特性：一次深刻的数值计算革新.NET 6 引入的“泛型数学”（Generic Math）预览特性，为 .NET 生态系统的数值计算领域带来了一场深刻的变革。过去，.NET 在处理数学运算时，往往受到静态类型系统的限制，使得编写通用、高效的数值算法变得冗长且充满样板代码。泛型.............
-
.NET 平台上的“BS 框架”（BrowserServer 框架，或者更常见的说法是 Web 框架）确实百花齐放，它们之间并非孤立存在，而是有着错综复杂的关系，并且各自在不同的场景下闪耀着实用价值。理解它们，就像梳理一个庞大生态系统中的脉络，能帮助我们更精准地选择适合的工具。咱们先从最底层、最基础.............
-
你这个问题触及了 .NET 生态系统里一个颇为现实且值得深思的现象，那就是第三方类库和框架的质量参差不齐。与其说“平均质量真的很差”，不如说 “普遍存在着巨大的质量差异，其中不乏一些质量堪忧的组件” 更加贴切。想象一下，.NET 作为一个庞大的、枝繁叶茂的生态系统，汇聚了无数开发者，其中有经验丰富的.............
-
.NET 的垃圾回收（Garbage Collection, GC）并非严格意义上的“定时执行”或“事件触发”，它是一个更为复杂且动态的过程，可以理解为由多种因素共同驱动，并根据系统的实际情况进行决策。你可以这样理解：.NET 的 GC 主要是在特定时机，根据内存使用情况自动启动。它不是按照固定的时.............
-
在 .NET Core 中，选择自旋锁（SpinLock）还是传统的 `lock` 语句（其背后是 `Monitor` 类）来管理多线程并发访问共享资源，其关键的开销差异主要体现在线程挂起与恢复的成本，以及CPU资源的占用方式上。让我们深入剖析一下：自旋锁 (SpinLock)： CPU 消耗 vs.............
-
.NET 程序卡死，这个现象确实可能跟之前修复过的漏洞有着千丝万缕的联系。我们不能简单地说“是”或者“不是”，而是需要理解其中的逻辑关系。想象一下，.NET 程序就像一个精密的机器，里面有无数个零件在按照预设的规则运转。这些零件就是代码，而规则就是程序的逻辑。有时候，这个机器会出现一些“小毛病”，比.............
-
在 .NET 的世界里，想要快速上手并构建一些小巧、高效的应用，确实有一些非常值得关注的框架。它们没有那种庞大和复杂的体系，上手成本低，而且能帮你迅速看到成果。如果你想做一个Web应用，最直观的选择就是 ASP.NET Core MVC。虽然名字里带着“MVC”，听起来好像会有点复杂，但实际上 AS.............
-
Net Explorer 和 Internet Explorer，名字听起来确实很像，很容易让人产生联想。但如果说 Net Explorer 能不能“代替”Internet Explorer，这得看你对“代替”的定义是什么。首先，我们要明白，Internet Explorer（IE）是微软推出的一款.............
-
.NET 框架在设计之初，就展现出了一个清晰的目标：构建一个统一、高效且跨平台的开发环境。将应用程序编程语言“统一”并非是简单地抛弃其他语言，而是通过一个强大的平台，让多种语言能够在此基础上和谐共存，协同工作。这背后蕴含着对开发者效率、代码复用、性能优化以及平台稳定性的深邃考量。首先，我们得理解“统.............
-
.NET 中利用 Razor 引擎生成代码，本质上是赋予你的 HTML 标记动态能力。Razor 视图引擎允许你将 C 代码片段无缝地嵌入到 HTML 标记中，从而实现服务器端的数据渲染。这种方式让你可以根据服务器上的数据动态地构建 HTML 结构，让页面内容变得鲜活起来。我们来深入探讨一下这个过程.............
-
.NET CLR（公共语言运行时）之所以能够处理“不安全”代码，尤其是那些涉及指针操作、内存访问等可能直接绕过类型检查和托管内存管理的低级操作，并非靠“保证”不挂掉，而是通过一套严谨的机制，将潜在的风险进行隔离、限制和管理，从而在大多数情况下维持程序的稳定运行。理解这一点至关重要：CLR 并不像一个.............
-
在.NET类库中，`HashCodeHelper`（或者更确切地说，是那些通过`HashCode.Combine`等方式生成哈希码的方法）的实现，其核心目标是提供一种组合多个值的哈希码生成机制。与直接使用单个对象的`GetHashCode()`方法不同，`HashCodeHelper`旨在将多个对象.............
-
在 .NET 开发中，如果你的应用程序需要将数据导出到 Excel 文件，并且你的目标用户可能安装了多个版本的 Microsoft Office（例如 Office 2010 和 Office 2019），那么你可能确实会遇到一个问题：如何控制你的应用程序在导出时具体调用哪个版本的 Office 组.............
-
.NET Core 的设计理念是跨平台，这意味着它能够运行在包括 ARM 在内的多种处理器架构上。这得益于 .NET Core 使用了像 RyuJIT 这样的即时编译器（JIT）以及其精心设计的运行时环境。RyuJIT 能够针对不同的 CPU 架构生成优化的机器码，因此 .NET Core 代码可以.............
-
.NET 的 `Dictionary` 并没有为 `IEqualityComparer` 提供一个普遍适用的默认实现，这背后其实是设计上的深思熟虑，旨在为开发者提供更大的灵活性和可控性，而不是为了偷懒或技术限制。让我们深入剖析一下原因。核心在于“相等”的定义并非一成不变当你使用 `Dictionar.............
-
在ASP.NET的Web.config文件中，`compilation`节点下的`debug`属性扮演着一个至关重要的角色，它直接影响着应用程序在开发和生产环境下的调试能力和性能表现。理解它背后的机制，能够帮助我们更好地管理和优化我们的.NET Web应用程序。首先，让我们深入了解`debug`属性.............
-
在 Web 开发的广阔领域里，.NET 和 Java 都是重量级的选手，各自拥有庞大的生态系统和忠实的拥趸。它们在构建现代 Web 应用方面都表现出色，但如果细究起来，它们在实现路径、设计哲学以及开发者体验上，确实存在着一些引人深思的差异。先来说说 .NET。它诞生于微软的怀抱，从一开始就带着一种“.............
-
在 .NET 中处理 JSON 序列化时，一个常见的需求是精确控制输出 JSON 中字段（属性）的命名，特别是首字母的大小写。这通常是为了遵循特定的 API 规范、提高代码的可读性，或者与其他系统进行数据交换。.NET 提供了多种方式来实现这一目标，其中最核心的工具是 `System.Text.Js.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有