C# CS8620警告：IEnumerable引用类型空性差异导致类型不匹配

问题根因 #

警告触发的核心是可空引用类型的类型推断不匹配：

1. FirstOrDefault()从ConcurrentBag<QueuedRequest>取值时，返回类型是QueuedRequest?——集合为空时该值为null
2. 用new[] { request }构造数组时，编译器会将数组类型推断为QueuedRequest?[]
3. LINQ的Except方法遇到可空类型的输入序列时，返回值类型为IEnumerable<QueuedRequest?>，但ConcurrentBag<QueuedRequest>的构造函数要求传入IEnumerable<QueuedRequest>（非空元素序列），空性差异直接触发CS8620警告。

你之前尝试将构造的ConcurrentBag泛型参数改为QueuedRequest?依然报错，是因为没有同步修改requests字段的声明类型，字段本身还是非空元素的ConcurrentBag类型，赋值时类型依然不匹配。
另外你当前取元素再重建集合移除元素的写法本身存在线程安全缺陷：取值和重新赋值的间隙如果有其他线程修改集合，会导致数据丢失。

最优修复方案（同时解决线程安全问题） #

直接使用ConcurrentBag原生提供的TryTake方法原子性地取出并移除元素，从根源上避免空值问题和线程安全问题，完全不会触发CS8620警告：

// 原子性尝试取出并移除第一个元素
if (this.requests.TryTake(out var request))
{
#pragma warning disable VSTHRD110 // Observe result of async calls
    Task.Run(() =>
#pragma warning restore VSTHRD110 // Observe result of async calls
    {
        // get notifications for report id
        var reportId = GetReportId(request);
        // 后续业务逻辑
    });
}

TryTake返回true时，out参数request保证非空，不需要额外做空检查；返回false说明集合为空，直接跳过逻辑即可。

其他可选修复方案 #

如果你因为业务原因必须保留原有重建集合的写法，可以选择以下任意一种方式修复：

方案1：过滤null值（推荐） #

提前判断request是否为null，同时过滤序列中可能存在的null值，明确告知编译器传入构造函数的序列全为非空元素：

var request = this.requests.FirstOrDefault();
// 集合为空直接返回
if (request == null)
{
    return;
}
this.requests = new ConcurrentBag<QueuedRequest>(this.requests
    .Except(new[] { request })
    .Where(item => item != null));

方案2：统一集合可空类型 #

如果业务允许集合中存储null值，同步修改字段声明和所有构造该集合的泛型参数为可空类型：

// 字段声明改为可空元素类型
private ConcurrentBag<QueuedRequest?> requests; 

// 对应赋值行同步修改
this.requests = new ConcurrentBag<QueuedRequest?>(this.requests.Except(new[] { request }));

注意使用该方案后，所有从集合中取出元素的位置都需要做null检查，避免空引用异常。

方案3：null原谅运算符（不推荐） #

如果你可以100%确认Except返回的序列中不存在null值，可以使用null原谅运算符!告知编译器跳过空性检查：

this.requests = new ConcurrentBag<QueuedRequest>(this.requests.Except(new[] { request })!);

该方案没有运行时校验，后续代码逻辑变更引入null元素时，会直接触发空引用异常，非必要不使用。

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