list1当和都是类型时， 和 中的项目顺序是否list2会不同？
list2 = list1.ToList()List
如果list1其顺序一致，则将list2采用相同的顺序。
有可能list1某种类型本身并不保证每次枚举时都具有相同的顺序，在这种情况下，两者当然可能会有所不同，但造成list1这种情况的是枚举逻辑，而不是ToList(). （名字list1表明它本身就是一个列表，在这种情况下顺序肯定是相同的）。
这里的一个答案已经包括ToList(). 它不是唯一ToList()存在的版本，并且 corefx 比 netfx 优化了更多的情况，但所有版本仍然以与源在枚举时提供的顺序相同的顺序生成列表。
另一个答案说，文档中不能保证这一点，只能通过对采用枚举的构造函数的重载的描述来保证List<T>（顺便说一句，这不是ToList()所有情况下所有实现都使用的唯一构造函数）。
ToList()然而，不承诺维持订单的更改将不会被接受。
考虑 的情况someSource.OrderBy(x => x.ID).ToList()。在这种情况下（顺便说一句，这是在 corefx 中优化的情况），如果ToList()可以更改顺序，显然会删除OrderBy().
好吧，如果有人改变的ToList()方式不承诺维持秩序，而是当作OrderBy()特殊情况怎么办？（毕竟，出于性能原因，在一个版本中这已经是一种特殊情况）。好吧，那还是会打破说someSource.OrderBy(x => x.ID).Where(x => !x.Deleted).ToList()。总而言之，如果我们有一个ToList()不维护顺序的版本，我们就能够提出某种 linq 查询，其中给定的顺序是由查询的另一部分承诺的，而这样的实现ToList()打破了承诺整个查询。
因此，除非对明确不承诺维持顺序的源进行特殊处理（ParallelEnumerable除非您使用 ，否则除非您使用AsOrdered()，否则除非在并行处理方面确实有必要，否则不维持顺序有很多优点），我们可以'ToList()在不破坏 linq 查询整体承诺的情况下，不要对不维持顺序的内容进行更改。
因此，虽然 的文档中没有提及该保证ToList()，但它仍然是有保证的，并且不会在以后的版本中更改。