为何先转换为 object 才能通过检查，却提示转换多余

2026-11-04技术老齐

结论

C# 的可空引用类型分析不会根据 Exists 推断列表中的所有元素今后都不为 null。检查完成后，如果要把 List<string?> 当作 List<string> 使用，仍需由程序员明确断言。

必须复用原来的 List 时，可以把检查和警告抑制集中到一个方法中：

using System.Diagnostics;

static List<T> AssertNoNullElements<T>(List<T?> source)
    where T : class
{
    if (source.Exists(static item => item is null))
    {
        throw new UnreachableException(
            "The list was expected to contain no null elements.");
    }

#pragma warning disable CS8619
    // 已逐项检查。这里保留同一个 List 实例，不复制元素。
    return source;
#pragma warning restore CS8619
}

调用处只需写：

List<string?> xs = new() { "a", "b" };

List<string> ys = AssertNoNullElements(xs);

这段代码不会创建新列表或复制元素，但调用方必须控制列表后续的修改，不能再通过 List<string?> 类型的引用向其中加入 null。

为什么直接赋值仍然有警告

string? 是编译期的可空性标注。对于引用类型，string 和 string? 在 CLR 中都是 System.String，所以：

List<string>
List<string?>

两者在运行时对应的都是 System.Collections.Generic.List<System.String>。

静态分析时，编译器仍会区分两者的可空性：

List<string> 按约定不应包含 null。
List<string?> 允许包含 null。

因此，下面的代码在运行时不需要类型转换，但编译器会报告可空性警告 CS8619：

List<string> ys = xs;

显式转换也不会改变可空性信息：

List<string> ys = (List<string>)xs;

这在 CLR 类型层面是恒等转换，编译器仍然知道源表达式的元素被标注为 string?。

为什么经过 object 后警告消失

下面的写法会切断可空性信息的传播：

List<string> zs = (List<string>)(object)xs;

转换为 object 后，表达式不再保留 List<string?> 的完整静态类型信息。第二次转换等于由程序员声明，这个对象应当视为 List<string>。

可空标注不会进入运行时类型，因此第二次转换能够成功。这个过程既不检查元素，也不修改列表内容，只会让编译器停止报告原来的可空性不匹配。

Rider 提示 Type cast is redundant，通常是从运行时类型转换的角度判断。List<string?> 和 List<string> 在 CLR 中是同一个类型，经过 object 的转换并没有改变对象。可空性分析与“冗余转换”检查关注的层面不同，所以两项检查会给出看似矛盾的结果。

这个提示属于 IDE 检查结果，并不表示 CLR 认为代码无法运行。

`!` 不能证明列表中的每个元素都非空

空宽容运算符也不能解决这个问题：

List<string> ys = xs!;

! 主要调整表达式本身的空状态。这里的 xs 已经是非空列表引用，问题在于它的元素类型是 string?。! 无法向编译器证明列表中的每个元素都是非空字符串。

用于单个元素时，! 可以表达这样的断言：

string value = xs[0]!;

如果允许创建新列表，也可以逐项消除可空性：

List<string> ys = xs.ConvertAll(static item => item!);

这样会分配一个新的 List<string>，不满足“不复制”的要求，但能建立独立且更稳定的类型约束。

复用同一列表时的风险

检查只能证明列表在检查当时不含 null，后续修改仍可能破坏这个条件：

List<string?> xs = new() { "a", "b" };
List<string> ys = AssertNoNullElements(xs);

xs.Add(null);

Console.WriteLine(ys[2].Length); // 可能抛出 NullReferenceException

xs 和 ys 指向同一个对象。通过 xs 加入的 null 也会出现在 ys 中，而编译器会按照 List<string> 的约定，将 ys[2] 视为非空字符串。

无复制方案适用于这些情况：

验证后不再保留或使用原来的 List<T?> 引用。
其他线程或组件不会并发修改列表。
当前代码明确拥有该列表。
相关约束集中封装在便于审查的位置。

如果无法满足这些条件，复制列表可以建立独立的数据边界，并非只有性能成本。

更合适的处理位置

如果返回 List<string?> 的方法能够保证所有元素都非空，应直接修正它的返回类型：

List<string> GetValues()
{
    // 方法内部保证不会返回 null 元素
}

这样调用方就不必再检查、转换或抑制警告。

如果该方法确实可能返回 null 元素，List<string?> 才是合适的签名。调用方有三种处理方式：

验证后复用同一实例，在封装方法中局部抑制 CS8619。
创建新的 List<string>，得到独立且可靠的非空集合。
保留 List<string?>，读取元素时分别处理可空性。

C# 当前的可空性流分析不会将 Exists、All 或一次 foreach 检查视为“集合元素类型已经永久细化”的证明。把断言集中封装并写明原因，比在业务代码中反复使用 (List<string>)(object)xs 更容易维护。