我主要在基于Windows和Windows CE的系统上工作，其中CreateFile，ReadFile和WriteFile是工作马，无论我是在Win32本地还是在托管中.Net土地。
我到目前为止从不在一个块中编写或读取大文件时遇到任何明显问题，而不是循环直到处理几个较小的块。我通常将IO工作委托给后台线程，该线程在完成后通知我。
但是看一下文件IO教程或“教科书示例”，我经常发现使用“小块循环”而没有解释为什么使用它而不是更明显（我敢说！）“做到这一切一次”。
我做的方式是否有任何缺点，我还没有理解？
澄清：
通过大文件我将我的单个块与多个块进行了比较。我提到的多个块示例通常在Windows CE上以1024字节的顺序具有块大小，在桌面上具有10倍的块大小。我的大文件通常是二进制文件，例如来自手机等的相机照片，因此大小顺序为2-10 MB。换句话说，不接近1 GB。
答案 0 :(得分：4)
通常，不应该假设流将一次读取所有数据。对于本地文件，可能是真的，它可能不适用于网络文件...并且它肯定不适用于一般网络流，除非更高级别已经缓冲它们。
然后是内存问题：假设有人要求您处理3GB文件。如果你流式传输，一次处理一个块，你没有问题。如果你试图将整个事物读入记忆中，那么你就不可能成功......
一般情况下：如果您可以流式传输，请执行此操作。为什么要使用效率较低且效率较低的方法？对于任何类型的稳健性，您仍然需要检查Read的返回值并将其与您预期读取的数量进行比较...因此添加循环不会导致非常很复杂。此外，如果你发现自己做了很多这样的事情，你很可能会发现你可以封装到辅助方法中的模式，很可能会让代表代表为处理而采取的自定义操作。
答案 1 :(得分：3)
这取决于你对“大”的定义。如果你只有2 GB的RAM（不包括虚拟内存），那么将10 GB文件读入内存会很幸运。
所以，一般来说，你总是需要做分块。这可能是教科书如此喜欢它的原因。只是块的大小才是讨论的重点。
当您处理流时，分块的另一个优点是内存使用率保持较低，并且与输入的大小无关。
但是，如果（且仅当）你知道你的文件大小有一些上限，而你的RAM下限，你可以一次完成。