正如我所理解的，.NET平台标准是一种提供合同以支持不同平台的方法。因此，我们不是编写应该运行平台A，B和C的代码，而是针对三个平台同时支持的.NET Platform Standard版本。
据我所知，动机是每个平台都有一个“基础库”（如BCL）。最后，我们的代码依赖于该基础库，因此我们需要知道哪些API可用。目标平台A，B和C使我们知道我们可以访问平台A，B和C的基础库中同时可用的API。
选择特定平台A，B和C的明显缺点是，如果出现另一个平台，其基础库中也包含我们需要的API，我们就无法使用它。
使用.NET平台标准，我们针对特定的“.NET级别”，因此我们支持符合该标准的平台。从某种意义上说，我们可以确信，对于特定的.NET平台标准，我们有一组API将存在于平台库中。
我的观点是：这里有一个从平台版本到API集合的映射。因此，对于.NET Standard 1.0，我们关联某个API列表，对于.NET Standard 1.1，我们将1.1中的相同列表与更多API相关联，依此类推至1.4。
在这种情况下，我们为每个.NET Standard版本挑选一个API列表。话虽这么说，一个数字就有很多信息。
这背后的原因是什么？这个单一数字怎么能包含这么多信息？什么定义了每个.NET标准平台级别支持哪些API？
答案 0 :(得分：0)
与PCL相比，Platform Standard尝试在一种新方法中解决兼容性问题，我们假设1.0版本与几个平台相匹配（尽管事实上这些平台并没有考虑到这样的标准）。然后在2.0版本中添加了一些新API，以便匹配平台升级。
因此，所有现有平台到标准平台版本的当前映射就像编写这些平台如何设计和发布的历史一样。
它更强调将来如何管理.NET生态系统。
例如，如果Microsoft和Xamarin（以及其他主要供应商）希望发布新的标准平台版本（规范），那么他们可以讨论要添加的新API。之后，每个供应商必须发布他们的新平台（.NET Framework / .NET Core / Xamarin.iOS等）以匹配新标准。否则，他们将失去在生态系统中的地位。
其他编程语言（如C ++）多年来一直在使用这种方法，它可以运行。查看C ++ 11，C ++ 14和C ++ 17。