从管理复杂性(一个主要的软件工程目标)的角度来看，我们希望避免将不必要的圈复杂性传播到API的客户端。向客户端返回null就像返回另一个代码分支的圈复杂度成本。

(这对应于单元测试负担。除了空集合返回情况外，您还需要为空返回情况编写一个测试。)

这取决于你的合同和具体情况。 通常最好返回空集合，但有时(很少):

Null可能意味着更具体的东西; 你的API(合约)可能会强制你返回null。

一些具体的例子:

一个UI组件(来自一个不受你控制的库)，如果传递一个空集合，可能会呈现一个空表，或者如果传递null，则根本不呈现表。 在Object-to-XML (JSON/其他)中，null表示元素缺失，而空集合将呈现冗余(可能不正确)<collection /> 你正在使用或实现一个明确声明null应该返回/传递的API

我喜欢在这里用适当的例子来解释。

考虑一个案例。

int totalValue = MySession.ListCustomerAccounts()
                          .FindAll(ac => ac.AccountHead.AccountHeadID 
                                         == accountHead.AccountHeadID)
                          .Sum(account => account.AccountValue);

这里考虑我使用的函数..

1. ListCustomerAccounts() // User Defined
2. FindAll()              // Pre-defined Library Function

我可以很容易地使用ListCustomerAccount和FindAll代替。

int totalValue = 0; 
List<CustomerAccounts> custAccounts = ListCustomerAccounts();
if(custAccounts !=null ){
  List<CustomerAccounts> custAccountsFiltered = 
        custAccounts.FindAll(ac => ac.AccountHead.AccountHeadID 
                                   == accountHead.AccountHeadID );
   if(custAccountsFiltered != null)
      totalValue = custAccountsFiltered.Sum(account => 
                                            account.AccountValue).ToString();
}

注意:由于AccountValue不为空，Sum()函数不会为空 返回null。因此我可以直接使用它。

视情况而定。如果是特殊情况，则返回null。如果函数恰好返回一个空集合，那么返回显然是可以的。但是，由于无效参数或其他原因而返回一个空集合作为特殊情况并不是一个好主意，因为它掩盖了一个特殊情况条件。

实际上，在这种情况下，我通常更喜欢抛出一个异常，以确保它真的没有被忽略:)

说它使代码更健壮(通过返回一个空集合)，因为它们不必处理null条件是不好的，因为它只是掩盖了应该由调用代码处理的问题。

还有一点尚未被提及。考虑下面的代码:

    public static IEnumerable<string> GetFavoriteEmoSongs()
    {
        yield break;
    }

在调用此方法时，c#语言将返回一个空枚举数。因此，为了与语言设计(以及程序员的期望)保持一致，应该返回一个空集合。

如果一个空集合在语义上是有意义的，那就是我喜欢返回的。为GetMessagesInMyInbox()返回一个空集合表示“您的收件箱中确实没有任何消息”，而返回null可能用于表示可用数据不足，无法说明可能返回的列表应该是什么样子。