当我编译这个项目时，它在错误列表窗口中显示了 400 多个错误，然后我转到错误站点，修复了一些错误，数字显示有 120 多个错误，然后修复了更多错误后，进行下一次编译再次报告400+。我可以看到错误列表窗口中出现了不同的文件，所以我认为编译器会在出现一定数量的错误后中止？
如果是这样，原因是什么？难道不应该收集项目中存在的所有错误，即使它们超过 10K+ 吗？
我一直想写一篇关于此的博客文章。
您可能只是遇到了报告错误数量的硬编码限制。您也可能遇到更微妙和有趣的场景。
命令行编译器和 IDE 编译器中有很多尝试管理错误报告的启发式方法。既可以让用户易于管理，又可以使编译器更加健壮。
简单地说，编译器的工作方式是尝试让程序经历一系列阶段，您可以在这里阅读：
http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx
这个想法是，如果早期阶段出现错误，我们可能无法成功完成后期阶段，除非（1）进入无限循环，（2）崩溃，或（3）报告疯狂的“级联”错误。所以发生的情况是，您遇到一个错误，修复它，然后突然可以运行下一阶段的编译，并发现更多错误。
基本上，如果程序非常混乱，以至于我们甚至无法验证有关其类和方法的基本事实，那么我们就无法可靠地给出方法体的错误。如果我们无法分析 lambda 主体，那么我们就无法可靠地给出将其转换为表达式树的错误。等等;在很多情况下，后面的阶段需要知道前面的阶段是否已完成而没有错误。
这种设计的优点是（1）你首先得到的是最“根本”的错误，没有很多嘈杂、疯狂的级联错误，（2）编译器更加健壮，因为它没有尝试对破坏了语言基本不变量的程序进行分析。不利的一面当然是您的情况：您有五十个错误，您将它们全部修复，然后突然又出现了五十个错误。
当然，它会在某个时刻停止。
即使出现 1 个错误，其余的最多也都是可疑的。编译器会尝试恢复，但这并不能保证成功。
因此，在任何重要的项目中，在出现第一个错误时停止（理论上是最好的做法）和在不可靠的状态下继续前进之间都是一个实际的决定。
最正确的操作是在出现 1 个错误后停止，但这会导致“一次修复 1 个”的乏味情况。因此，编译器尝试重新同步到已知状态并报告下一个状态。但是错误可能会导致其后面的正确代码出现错误，因此在某些时候它就不再明智了。
参考你自己的情况：经过一些修复后，400+变成了120。
可根据MSDN
进行配置默认情况下，最大数量为 200 个错误和警告。