为什么这个方法会导致无限循环？

我的一位同事向我提出了关于这种导致无限循环的方法的问题。实际的代码有点复杂，无法在这里发布，但本质上问题归结为：

private IEnumerable<int> GoNuts(IEnumerable<int> items)
{
    items = items.Select(item => items.First(i => i == item));
    return items;
}

This should（您可能会认为）只是创建列表副本的一种非常低效的方法。我用以下方式调用它：

var foo = GoNuts(new[]{1,2,3,4,5,6});

结果是无限循环。奇怪的。

我认为修改参数在风格上是一件坏事，所以我稍微改变了代码：

var foo = items.Select(item => items.First(i => i == item));
return foo;

那行得通。即程序完成；没有例外。

更多实验表明这也有效：

items = items.Select(item => items.First(i => i == item)).ToList();
return items;

就像一个简单的

return items.Select(item => .....);

Curious.

很明显，问题与重新分配参数有关，但前提是评估被推迟到该语句之外。如果我添加ToList()有用。

我对出了什么问题有一个大致的、模糊的想法。它看起来像Select正在迭代它自己的输出。这本身有点奇怪，因为通常IEnumerable如果正在迭代的集合发生变化，将会抛出异常。

我不明白的是，因为我不太熟悉这个东西的工作原理，所以重新分配参数会导致这个无限循环。

有没有更了解内部原理的人愿意解释为什么这里会发生无限循环？

回答这个问题的关键是延迟执行。当你这样做时

items = items.Select(item => items.First(i => i == item));

you do not迭代items数组传递到方法中。相反，您为其分配一个新的IEnumerable<int>，它引用自身，并且仅当调用者开始枚举结果时才开始迭代。

这就是为什么你的所有其他修复都解决了这个问题：你所需要做的就是停止喂食IEnumerable<int>回到自身：

• Using var foo通过使用不同的变量来打破自引用，
• Using return items.Select...根本不使用中间变量来破坏自引用，
• Using ToList()通过避免延迟执行来打破自引用：到时候items被重新分配，旧的items已经被迭代了，所以你最终会得到一个简单的内存List<int>.

但如果它以自身为食，它是如何获得任何东西的呢？

没错，它什么也没得到！当你尝试迭代的那一刻items并询问第一个项目，延迟序列询问提供给它的序列以处理第一个项目，这意味着该序列正在询问自己要处理的第一个项目。此时，就是海龟一路下来 https://en.wikipedia.org/wiki/Turtles_all_the_way_down，因为为了返回要处理的第一个项目，序列必须首先从其自身获取要处理的第一个项目。