.NET Standard 2.1中为何未触发CS8604（可为空引用参数）警告？
这个问题确实挺让人摸不着头脑的，我来帮你拆解一下背后的原因：
首先可以明确的是，这不是编译器bug，而是不同目标框架下，可为空引用类型（NRT）的分析规则差异导致的。
你观察到的现象很关键：b的CS8602警告正常触发，说明nullable上下文确实在工作，但a调用Count()时没有CS8604警告——这是因为针对.NET Standard 2.1和.NET 8+这类具体框架，编译器的NRT分析覆盖范围是不一样的：
CS8602和CS8604的检查逻辑差异
CS8602是直接解引用可能为空的引用（比如b.Length这种直接访问成员的操作），这是NRT最基础的检查能力，在.NET Standard 2.1中已经完全支持，所以你能看到警告。
而CS8604是将可能为空的引用传递给要求非空引用的方法参数——这里Count()是Enumerable的扩展方法，它的this参数要求的是IEnumerable<string>（非空），你传入的a是IEnumerable<string>?（可为空），这种场景的检查规则在不同目标框架下有区别。.NET Standard 2.1的NRT支持局限性
.NET Standard本质是一个跨平台的兼容规范，它的NRT分析规则是“最小兼容集”，为了适配它要兼容的各种旧版.NET环境，编译器会禁用一些在新版具体框架中才启用的严格检查。
其中就包括扩展方法的this参数的空值传递检查：在.NET Standard 2.1的目标下，编译器不会为“将可为空接口类型参数传给扩展方法的非空this参数”触发CS8604警告；而当你切换到.NET 8.0这类具体的现代框架时，编译器会启用更完整的NRT分析，自然就会触发对应的CS8604警告了。SDK版本 vs 目标框架的关系
你用的是.NET 9 SDK，但目标框架是.NET Standard 2.1，这时候编译器会自动适配目标框架的规则，而不是直接用最新SDK的全部严格规则——这是为了保证代码在所有兼容.NET Standard 2.1的环境下的行为一致性，避免引入在旧环境中不兼容的警告。
备注：内容来源于stack exchange，提问作者Luke Vo
