人們已經(jīng)無數(shù)次證明，那yield return比list.但是，當(dāng)我嘗試基準(zhǔn)測試時，得到了相反的結(jié)果：Results:TestYield: Time =1.19 secTestList : Time =4.22 sec在這里，List 慢了 400%。無論大小都會發(fā)生這種情況。這是沒有意義的。IEnumerable<int> CreateNumbers() //for yield{    for (int i = 0; i < Size; i++) yield return i;}IEnumerable<int> CreateNumbers() //for list{    var list = new List<int>();    for (int i = 0; i < Size; i++) list.Add(i);    return list;}以下是我使用它們的方式：foreach (var value in CreateNumbers()) sum += value;我使用所有正確的基準(zhǔn)規(guī)則來避免結(jié)果沖突，所以這不是問題。如果你看到底層代碼，yield return它是一個狀態(tài)機可憎，但它更快。為什么？編輯：所有答案都被復(fù)制，確實產(chǎn)量比列表快。New Results With Size set on constructor:TestYield: Time =1.001TestList: Time =1.403From a 400% slower difference, down to 40% slower difference.然而，這些見解令人心碎。這意味著所有那些從 1960 年起使用 list 作為默認(rèn)集合的程序員都是錯誤的，應(yīng)該被解雇（解雇），因為他們沒有使用最好的工具來解決這種情況（yield）。答案認(rèn)為，收益率應(yīng)該更快，因為它沒有實現(xiàn)。1）我不接受這個邏輯。Yield 背后有內(nèi)部邏輯，它不是“理論模型”，而是編譯器構(gòu)造。因此，它會在消費時自動實現(xiàn)。我不接受它“沒有實現(xiàn)”的論點，因為成本已經(jīng)在使用時支付。2）如果船可以走海路，而老婦人不行，你不能要求船“走陸路”。正如你在這里對列表所做的那樣。如果一個列表需要具體化，而 yield 不需要，那不是“產(chǎn)量問題”，而是一個“特性”。不應(yīng)僅僅因為它有更多用途而在測試中懲罰產(chǎn)量。3）我在這里爭論的是，如果您知道整個 SET將被消耗，那么測試的目的是找到“最快的集合”來消耗/返回方法返回的結(jié)果。yield 是否成為從方法返回列表參數(shù)的新“事實上的標(biāo)準(zhǔn)”。Edit2：如果我使用純內(nèi)聯(lián)數(shù)組，它會獲得與 Yield 相同的性能。Test 3:TestYield: Time =0.987TestArray: Time =0.962TestList: Time =1.516int[] CreateNumbers(){    var list = new int[Size];    for (int i = 0; i < Size; i++) list[i] = i;    return list;}因此，yield 會自動內(nèi)聯(lián)到數(shù)組中。列表不是。