多年来，我自己也在想这个问题。但我今天遇到了一个很好的理由。

想象一个每行都有记录的文件（例如：CSV文件）。电脑在文件末尾写记录。但它突然坠毁了。天哪，最后一行完成了吗？（情况不太好）

但是如果我们总是终止最后一行，那么我们就会知道（只需检查最后一行是否终止）。否则，为了安全起见，我们可能不得不每次都放弃最后一行。

除了上述实际原因之外，如果Unix的创始人（Thompson、Ritchie等人）或他们的Multics前辈意识到使用行终结符而不是行分隔符是有理论原因的，我也不会感到惊讶：使用行终结器，您可以对所有可能的行文件进行编码。使用行分隔符，零行文件和包含单个空行的文件之间没有区别；它们都被编码为包含零字符的文件。

因此，原因如下：

因为POSIX就是这样定义它的。因为有些工具期望它或没有它的“错误行为”。例如，wc-l不会计算最后的“行”，如果它不以换行结尾。因为它简单方便。在Unix上，cat只起作用，而且没有任何复杂的问题。它只复制每个文件的字节，不需要任何解释。我不认为DOS等同于猫。使用副本a+b c将最终将文件a的最后一行与文件b的第一行合并。因为零行的文件（或流）可以与一个空行的文件区分开来。

我一直觉得，在解析一个没有结尾换行符的文件时，这条规则是很困难的。也就是说，您最终会编写代码，其中行的结尾由EOL字符或EOF定义。假设一行以EOL结尾比较简单。

然而，我相信这个规则是从需要换行符的C编译器派生出来的。正如“文件末尾没有换行符”编译器警告所指出的，#include不会添加换行符。

我个人喜欢源代码文件末尾的新行。

它可能起源于Linux或所有UNIX系统。我记得有编译错误（如果我没弄错的话是gcc），因为源代码文件没有以空的新行结尾。为什么会这样呢。

每一行都应该以换行符结尾，包括最后一行。有些程序在处理文件的最后一行时遇到问题，如果它不是换行符。

GCC对此发出警告，并不是因为它无法处理文件，而是因为它必须作为标准的一部分。

C语言标准说非空的源文件应以换行符结尾，换行符前不得紧跟反斜杠字符。由于这是一个“应”条款，我们必须发出一条违反此规则的诊断信息。这在ANSI C 1989标准第2.1.1.2节中。ISO C 1999标准（可能还有ISO C 1990标准）第5.1.1.2节。

参考：GCC/GNU邮件存档。

假设文件正在被处理，而文件仍由另一个进程生成。

可能与此有关？指示文件已准备好处理的标志。