C#启用Nullable时Debug.Assert导致CS8603警告失效问题

基于 .NET 6、C# 10 开发的程序集已开启 <Nullable>enabled</Nullable> 配置，正常情况下返回null的非可空引用类型返回值函数会触发CS8603编译警告：

object[] Foo()
{
    return null;  // 正常触发 CS8603 警告
}

要消除该警告，必须将返回类型修改为可空引用类型 object[]?。

当函数中包含 Debug.Assert(false); 语句时，即使返回null也不会触发CS8603警告，示例代码如下：

public object[] ConvertBack(object v, Type[] t, object p, CultureInfo c)
{   
    Debug.Assert(false);
    return null;  // 移除Assert语句前不会触发CS8603警告
}

该现象和预期不符：无论Debug构建还是Release构建，上述代码都不会产生警告，只有移除Debug.Assert语句后，两种构建模式才会正常生成警告。
已知Debug.Assert按设计仅会在定义了DEBUG编译符号的版本中生效，且已确认Release构建设置中并未定义DEBUG符号。

这个现象是C#编译器可空性流分析的设计行为，和Debug/Release构建模式无关，核心逻辑如下：

• C#的可空引用类型警告基于源码静态流分析实现，分析阶段发生在条件编译裁剪之前，不会因为某段代码最终会被[Conditional]特性移除，就忽略它对代码可达性的影响。
• Debug.Assert方法的参数上标注了[DoesNotReturnIf(false)]特性：这个特性是给编译器的契约提示，说明当传入Assert的参数值为false时，程序执行到Assert方法就会中断（要么弹出断言对话框终止，要么抛出断言失败异常），绝对不会继续执行后续代码。
• 当代码中写了Debug.Assert(false)时，编译器直接根据这个特性判定：这行代码之后的所有代码都是不可达的死代码。
• 可空性检查规则明确不会对不可达代码触发警告——既然编译器判定return null;永远不可能被执行，自然就不会报CS8603的返回类型不匹配警告。
• Release构建下同样不触发警告的原因也很简单：流分析读取的是原始源码内容，只要源码里存在这行Assert调用，编译器就会应用对应的可达性判定，不会因为Release模式下这行调用最终会被编译裁剪，就改变分析结果。

注意：这个行为很容易埋下逻辑隐患：Release模式下Debug.Assert(false)会被完全移除，后续的return null;会被真实执行，最终违反非可空返回值的契约，但编译器因为可达性判定漏掉了这个警告。如果要标记某条代码路径不可达，建议直接抛出对应异常，不要用Assert加占位return的写法。

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