为何调用链中可省略后续空条件运算符？拆分代码报错解析

这个问题问到点子上了！核心原因是C#空条件运算符（?.）的链式短路特性，它的工作方式可能比你直觉里的更“智能”，咱们一步步拆解：

1. 链式调用的本质：编译器帮你做了整体条件判断 #

先看你提到的能正常运行的代码：

IEnumerable<int>? tt = null;
var yy = tt?.Where(x => x > 5).Select(x => x.ToString());

你可能误以为这段代码是先执行tt?.Where(...)得到一个可能为null的结果，再对这个结果调用Select(...)——但实际上编译器会把整个链式调用翻译成类似这样的逻辑：

var yy = tt != null ? tt.Where(x => x > 5).Select(x => x.ToString()) : null;

也就是说：

• 如果tt不为null，才会依次执行Where和Select（这时候Where返回的是LINQ标准的非null枚举，Select自然能正常调用）；
• 如果tt是null，整个表达式直接返回null，根本不会去执行Where，更不会尝试对null调用Select。

这就是短路求值的延伸——不是对每一步的结果做空判断，而是对链式调用的起始对象做一次判断，只要起始对象为空，整个后续调用链直接“短路”返回null。

2. 拆分代码后报错的原因 #

当你把代码拆成两行：

var temp = tt?.Where(x => x > 5);
var yy = temp.Select(x => x.ToString()); // 这里会报错

此时temp的类型是IEnumerable<int>?（可空引用类型），它确实可能为null（当tt是null时）。这时候你直接调用temp.Select(...)，相当于对一个可能为空的引用执行成员调用，编译器会触发可空引用类型的警告（或错误，取决于你的项目设置），运行时也会抛出ArgumentNullException或NullReferenceException。

3. 澄清一个误解：?.Where(...)不会平白返回null #

你提到“原本认为必须在Select前使用?.运算符，因为?.Where(...)会返回null”——其实LINQ的标准查询操作符（比如Where）永远不会返回null，哪怕结果是空集合，也会返回一个空的、非null的IEnumerable实例。tt?.Where(...)只有在tt本身为null时才会返回null，其他情况都是非null的枚举对象。

总结一下：空条件运算符的链式短路特性，让你只需要在链式调用的第一个可能为空的对象前加?.，后续的成员/方法调用都会被编译器自动纳入短路逻辑，无需重复添加?.。

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