首先，没有特别好的理由去使用
fdopenif
fopen是一个选项，
open而另一个是可能的选择。如果您要使用
open，则不应该首先使用该文件
FILE*。因此，将其包括
fdopen在该列表中是不正确且令人困惑的，因为它与其他列表不太相似。现在，我将继续忽略它，因为此处的重要区别在于C标准
FILE*和OS特定的文件描述符之间。
使用
fopen而不是的主要原因有四个
open。
fopen
为您提供缓冲IO，结果可能会比您执行的要快得多open
。fopen
如果未以二进制模式打开文件，则执行行结尾翻译，如果您的程序曾经移植到非Unix环境（尽管世界似乎仅在LF上融合（基于IETF文本的网络除外），这将非常有帮助SMTP和HTTP等协议））。- A
FILE *
使您能够使用fscanf
和其他stdio功能。 - 您的代码可能有一天需要移植到仅支持ANSI C而不支持该
open
功能的其他平台。
在我看来，以行结尾的翻译不但不会帮助您，反而会给您
fscanf带来更多麻烦，而且对它的解析是如此微弱，以至于您不可避免地最终将其抛弃，而转向了更有用的东西。
并且大多数支持C的平台都具有
open功能。
这留下了缓冲问题。在主要按顺序读取或写入文件的地方，缓冲支持确实很有帮助，并且可以大大提高速度。但是，这可能会导致一些有趣的问题，即当您希望数据存在于文件中时，数据不会最终出现在文件中。您必须记住
fclose或
fflush在适当的时候。
如果您正在执行搜索（又名
fsetpos或
fseek第二种，以符合标准的方式使用起来比较棘手），则缓冲的有用性会迅速下降。
当然，我的偏见是我倾向于大量使用套接字，并且事实是您真的想做无阻塞的IO（它
FILE*完全无法以任何合理的方式支持）并且根本没有缓冲。复杂的解析要求确实使我的看法蒙上了一层阴影。
