我们有没有理由在Directory.EnumerateFiles（）上使用Directory.GetFiles（）？
我不知道为什么我们会使用Directory.GetFiles ，如果Directory.EnumerateFiles能够做同样的事情，你甚至可以在返回找到的整个目录列表之前枚举列表。
Directory.EnumerateFiles与Directory.GetFiles有什么区别？
为什么，既然EnumerateFiles可用，是否需要使用GetFiles ？
根据http://msdn.microsoft.com/en-us/library/07wt70x2%28v=vs.110%29.aspx ：
EnumerateFiles和GetFiles方法的不同之处如下：使用EnumerateFiles时，可以在返回整个集合之前开始枚举名称集合; 当您使用GetFiles时，您必须等待返回整个数组的名称，然后才能访问该数组。 因此，当您使用许多文件和目录时，EnumerateFiles可以更高效。
我猜GetFiles可以被认为是一个方便的function。
您使用正确的工具来完成正确的工作。 如果您有少量文件，那么您可能只想使用Directory.GetFiles()并将它们加载到内存中。
另一方面， Directory.EnumerateFiles()是您需要通过一次枚举一个文件来节省内存的时候。
这类似于是否使所有内容变得 懒惰 ，或者在适当时使用它的论点。 我认为这有助于把事情放在眼里，因为没有充分理由让一切都变得懒散是有点过分的。
你有简单与效率的权衡。 从概念上讲，一个实际上不包含文件但一次生成一个文件的枚举器比字符串数组更复杂。 能够将该枚举器存储在IEnumerable是一个很好的抽象，但重点仍然存在。
预测绩效可能也更困难。 使用GetFiles()您知道调用方法时会产生性能成本。 EnumerateFiles()在EnumerateFiles()之前不会执行任何操作。
意图很重要。 如果你在一个你知道没有那么多文件的目录上使用EnumerateFiles() ，那么你只是盲目地使用它而不理解。 代码运行的计算机也很重要。 如果我在具有24 GB RAM的服务器上运行某些东西，那么我可能更有可能使用像GetFiles()那样的内存饥饿方法，而不是使用1 GB RAM的服务器。
如果您不知道将有多少文件或不确定代码将在何种环境中运行，那么谨慎行事并使用内存高效版本是明智之举。
有许多变量需要考虑，优秀的程序员会考虑这些因素并有目的地做事。
这两种方法最终都会调用System.IO.FileSystemEnumerableFactory.CreateFileNameIterator（）。 唯一的区别似乎是GetFiles（）结果被包装在List中，然后变成一个数组。 正如在其他一些答案中所提到的，不同之处在于枚举器已经通过GetFiles（）与EnumerateFiles进行了遍历，EnumerateFiles在遍历它之前为您提供了枚举器。
作为参考，我能够使用ILSpy（ http://ilspy.net/ ）找到这个