我想这里的每个人都熟悉这句谚语，即所有文本文件都应该以换行符结尾。我已经知道这个“规则”很多年了，但我一直在想——为什么？
当前回答
现在已经很晚了，但我在文件处理中遇到了一个错误，这是因为文件没有以空换行结尾。我们使用sed处理文本文件，sed省略了输出的最后一行，这导致无效的json结构，并将流程的其余部分发送到失败状态。
我们所做的就是：
有一个示例文件，比如：foo.txt，其中包含一些json内容。
[{
someProp: value
},
{
someProp: value
}] <-- No newline here
该文件是在寡妇计算机中创建的，窗口脚本正在使用PowerShell命令处理该文件。一切都很好。
当我们使用sed命令sed的|value|newValue|g'foo.txt>foo.txt.tmp处理同一文件时
新生成的文件是
[{
someProp: value
},
{
someProp: value
和boom，由于无效的JSON，它使其余过程失败。
因此，用空的新行结束文件始终是一个好的做法。
其他回答
很可能只是一些解析代码希望它在那里。
我不确定我是否会认为这是一条“规则”，而且这肯定不是我虔诚地遵守的。最明智的代码将知道如何逐行解析文本（包括编码）（任何行结尾的选择），最后一行是否有换行符。
的确，如果你以一条新的线结束：EOL和EOF之间（理论上）是否有一条空的最终线？一个值得思考的。。。
假设文件正在被处理，而文件仍由另一个进程生成。
可能与此有关？指示文件已准备好处理的标志。
除了上述实际原因之外，如果Unix的创始人（Thompson、Ritchie等人）或他们的Multics前辈意识到使用行终结符而不是行分隔符是有理论原因的，我也不会感到惊讶：使用行终结器，您可以对所有可能的行文件进行编码。使用行分隔符，零行文件和包含单个空行的文件之间没有区别；它们都被编码为包含零字符的文件。
因此，原因如下：
因为POSIX就是这样定义它的。因为有些工具期望它或没有它的“错误行为”。例如，wc-l不会计算最后的“行”，如果它不以换行结尾。因为它简单方便。在Unix上，cat只起作用，而且没有任何复杂的问题。它只复制每个文件的字节，不需要任何解释。我不认为DOS等同于猫。使用副本a+b c将最终将文件a的最后一行与文件b的第一行合并。因为零行的文件（或流）可以与一个空行的文件区分开来。
这源于使用简单终端的早期。换行符用于触发传输数据的“刷新”。
今天，不再需要换行符。当然，如果没有换行符，许多应用程序仍然存在问题，但我认为这是这些应用程序中的一个错误。
然而，如果你有一个需要换行符的文本文件格式，那么你可以得到非常便宜的简单数据验证：如果文件以结尾没有换行符的行结尾，那么你就知道文件已损坏。每行只有一个额外的字节，您可以高精度地检测损坏的文件，几乎不需要CPU时间。
多年来，我自己也在想这个问题。但我今天遇到了一个很好的理由。
想象一个每行都有记录的文件（例如：CSV文件）。电脑在文件末尾写记录。但它突然坠毁了。天哪，最后一行完成了吗？（情况不太好）
但是如果我们总是终止最后一行，那么我们就会知道（只需检查最后一行是否终止）。否则，为了安全起见，我们可能不得不每次都放弃最后一行。
