.NET Standard中未支持的System.Web类仍可访问的原因是什么？

核心原因：.NET Standard 2.0的.NET Framework兼容桥接 #

.NET Standard 2.0的设计初衷之一是最大化兼容现有.NET Framework 4.x代码，降低移植门槛。为此它引入了特殊的兼容层：允许类库编译时引用.NET Framework的核心程序集（包括System.Web），即使这些API并不属于.NET Standard的官方规范。

这种设计的本质是“编译时允许访问，运行时按需兼容”——在.NET Framework运行时上，这些System.Web API能正常工作；但如果把类库部署到.NET Core/.NET 6+等非.NET Framework环境，调用未被移植的API（如System.Web.Caching、System.Web.Security）会直接抛出PlatformNotSupportedException。

而.NET 6/8属于.NET Core的后续演进版本，完全抛弃了对.NET Framework兼容层的依赖，只保留了System.Web中被移植到跨平台实现的极小部分（比如HttpUtility，通常通过System.Web.HttpUtility NuGet包提供），所以编译时无法访问其他未移植的API。

为什么会出现“无警告编译”的情况 #

默认情况下，.NET Standard 2.0项目不会对引用.NET Framework API的代码发出警告，这是为了避免移植大量旧代码时产生过多噪音，但也导致了潜在风险——开发者可能无意识地使用了无法跨平台运行的API。

除了代码分析器，还能做这些来规避风险 #

• 启用平台兼容性警告：在项目文件中添加以下配置，启用CS1701（程序集引用可能不兼容）和CA1416（平台兼容性验证）规则，让编译器对跨平台不兼容的API调用发出警告或错误：

  <PropertyGroup>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>
  <ItemGroup>
    <Analyzer Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="7.0.0" />
  </ItemGroup>
  

• 禁用.NET Framework程序集的隐式引用：在项目文件中设置<DisableImplicitFrameworkReferences>true</DisableImplicitFrameworkReferences>，强制项目只引用.NET Standard规范内的程序集，彻底屏蔽System.Web等非标准API的编译时访问。
• 使用跨平台替代API：引导团队使用System.Web API的跨平台替代方案，比如用Microsoft.Extensions.Caching替代System.Web.Caching，用System.Security.Claims替代System.Web.Security相关功能。

内容的提问来源于stack exchange，提问作者user15890395