Go似乎是首选nil而不是空数组的一种语言。

https://github.com/golang/go/wiki/CodeReviewComments#declaring-empty-slices

当声明一个空切片时，优先使用var t []string而不是t:= []string{}。前者声明一个nil切片值，而后者非nil但长度为0。它们在功能上是等价的——它们的len和cap都是0——但是nil片是首选样式。

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

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

一些具体的例子:

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

我认为null与空集合不同，您应该选择哪一个最能代表您要返回的内容。在大多数情况下，null什么都不是(SQL除外)。空的收藏是一种东西，尽管是一种空的东西。

如果你不得不选择一个或另一个，我会说你应该倾向于一个空集合而不是null。但有时空集合与空值并不相同。

大约一周前，我们在开发团队中讨论过这个问题，我们几乎一致同意采用空收集。有人想要返回null，原因与Mike上面指定的相同。

空集合。如果您正在使用c#，那么假定最大化系统资源并不是必要的。虽然效率较低，但返回Empty Collection对于所涉及的程序员来说要方便得多(出于Will在上面概述的原因)。

I call it my billion-dollar mistake…At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. – Tony Hoare, inventor of ALGOL W.

See here for an elaborate shit storm about null in general. I do not agree with the statement that undefined is another null, but it is still worth reading. And it explains, why you should avoid null at all and not just in the case you have asked. The essence is, that null is in any language a special case. You have to think about null as an exception. undefined is different in that way, that code dealing with undefined behavior is in most cases just a bug. C and most other languages have also undefined behavior but most of them have no identifier for that in the language.