我想这里的每个人都熟悉这句谚语，即所有文本文件都应该以换行符结尾。我已经知道这个“规则”很多年了，但我一直在想——为什么？
当前回答
这个答案是一个技术性的答案，而不是观点。
如果我们想成为POSIX纯粹主义者，我们将一行定义为：
一个由零个或多个非<换行符>字符加上一个终止<换行符]字符组成的序列。
资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
不完整的行，如：
文件末尾的一个或多个非<换行符>字符序列。
资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195
文本文件为：
包含组织成零行或多行的字符的文件。这些行不包含NUL字符，长度不能超过｛LINE_MAX｝字节，包括＜换行符＞字符。虽然POSIX.1-2008没有区分文本文件和二进制文件（参见ISO C标准），但许多实用程序在操作文本文件时只产生可预测或有意义的输出。具有此类限制的标准实用程序总是在其STDIN或INPUT files部分中指定“文本文件”。
资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397
字符串为：
一个连续的字节序列，以第一个空字节结尾并包括第一个空字符。
资料来源：https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396
由此，我们可以得出，只有当我们处理文件的一行或文件作为文本文件的概念时，我们才可能遇到任何类型的问题（即文本文件是由零行或多行组成的组织，并且我们知道的行必须以＜newline＞结尾）。
大小写：wc-l文件名。
从wc手册中，我们了解到：
行定义为一个由＜newline＞字符分隔的字符串。
如果JavaScript、HTML和CSS文件是文本文件，那么它们的含义是什么？
在浏览器、现代IDE和其他前端应用程序中，在EOF时跳过EOL没有问题。应用程序将正确解析文件。由于并非所有操作系统都符合POSIX标准，因此非OS工具（例如浏览器）根据POSIX标准（或任何OS级标准）处理文件是不切实际的。
因此，我们可以相对确信，EOF的EOL在应用程序级别几乎不会产生负面影响——无论它是否在UNIX OS上运行。
此时，我们可以自信地说，在客户端处理JS、HTML和CSS时，在EOF中跳过EOL是安全的。实际上，我们可以声明，缩小其中任何一个不包含＜newline＞的文件都是安全的。
我们可以进一步说，就NodeJS而言，它也不能遵守POSIX标准，因为它可以在非POSIX兼容的环境中运行。
那我们还剩什么？系统级工具。
这意味着唯一可能出现的问题是那些努力使其功能符合POSIX语义的工具（例如wc中所示的行的定义）。
即使如此，并不是所有的shell都会自动遵守POSIX。例如，Bash不默认为POSIX行为。有一个开关可以启用它：POSIXLY_CORRECT。
EOL的价值值得思考：https://www.rfc-editor.org/old/EOLstory.txt
为了所有实际意图和目的，让我们继续走在工具轨道上，考虑一下：
让我们处理一个没有EOL的文件。至此，本例中的文件是一个缩小的JavaScript，没有EOL。
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js
$ cat x.js y.js > z.js
-rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 x.js
-rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 y.js
-rw-r--r-- 1 milanadamovsky 15810 Aug 14 23:18 z.js
请注意，cat文件大小正好是其各个部分的总和。如果JavaScript文件的连接是JS文件的一个问题，那么更合适的问题是用分号开始每个JavaScript文件。
正如其他人在本主题中提到的：如果你想抓取两个输出仅为一行而不是两行的文件，该怎么办？换句话说，猫做它应该做的事。
猫的男人只提到阅读输入到EOF，而不是＜newline＞。请注意，cat的-n开关还将打印出一个非<换行符>终止的行（或不完整的行）作为一行，即计数从1开始（根据man的说法）
-n对输出线进行编号，从1开始。
现在我们了解了POSIX是如何定义行的，这种行为变得模棱两可，或者说实际上是不合规的。
了解给定工具的用途和合规性将有助于确定使用EOL结束文件的重要性。在C、C++、Java（JARs）等中，一些标准会规定一个新的有效性标准——JS、HTML、CSS不存在这样的标准。
例如，可以不使用wc-l文件名，而是使用awk“｛x++｝END｛print x｝”文件名，并确保任务的成功不会受到我们可能要处理的文件（例如，第三方库，例如我们固化的精简JS）的影响，除非我们的目的是真正按照POSIX兼容的方式计算行数。
结论
在现实生活中，对于某些文本文件（如JS、HTML和CSS），在EOF时跳过EOL会产生负面影响（如果有的话）。如果我们依赖于＜newline＞的存在，我们将工具的可靠性限制在我们编写的文件上，并将自己暴露在第三方文件引入的潜在错误中。
故事的寓意：工程师工具没有依赖EOF中EOL的弱点。
请随意发布用例，因为它们适用于JS、HTML和CSS，我们可以在其中检查跳过EOL是如何产生不利影响的。
其他回答
很可能只是一些解析代码希望它在那里。
我不确定我是否会认为这是一条“规则”，而且这肯定不是我虔诚地遵守的。最明智的代码将知道如何逐行解析文本（包括编码）（任何行结尾的选择），最后一行是否有换行符。
的确，如果你以一条新的线结束：EOL和EOF之间（理论上）是否有一条空的最终线？一个值得思考的。。。
基本上，如果没有得到最终EOL EOF，许多程序将无法正确处理文件。
GCC警告您这一点，因为它是C标准的一部分。（第5.1.1.2节明显）
“文件末尾没有换行符”编译器警告
每一行都应该以换行符结尾，包括最后一行。有些程序在处理文件的最后一行时遇到问题，如果它不是换行符。
GCC对此发出警告，并不是因为它无法处理文件，而是因为它必须作为标准的一部分。
C语言标准说非空的源文件应以换行符结尾，换行符前不得紧跟反斜杠字符。由于这是一个“应”条款，我们必须发出一条违反此规则的诊断信息。这在ANSI C 1989标准第2.1.1.2节中。ISO C 1999标准（可能还有ISO C 1990标准）第5.1.1.2节。
参考：GCC/GNU邮件存档。
我个人喜欢源代码文件末尾的新行。
它可能起源于Linux或所有UNIX系统。我记得有编译错误（如果我没弄错的话是gcc），因为源代码文件没有以空的新行结尾。为什么会这样呢。
为什么文本文件应该以换行符结尾？
因为这是最明智的选择。
获取包含以下内容的文件：，
one\n
two\n
three
其中，\n表示换行符，在Windows上是返回字符，\r\n后跟换行符，因为它很酷，对吗？
这个文件有多少行？Windows说3，我们说3，POSIX（Linux）说文件是残缺的，因为文件末尾应该有一个。
无论如何，你会说它的最后一行是什么？我想任何人都同意三行是文件的最后一行，但POSIX表示这是一个残缺的行。
第二行是什么？哦，这里有第一个强烈的分离：
Windows说两个是因为文件是“用换行符分隔的行”（wth？）；POSIX说2，并补充说这是一条真实、诚实的路线。
那么，选择Windows的后果是什么？简单：
你不能说文件是由行组成的
为什么？尝试从上一个文件中取出最后一行并复制几次。。。你得到了什么？这：
one\n
two\n
threethreethreethree
相反，尝试交换第二行和第三行。。。你会发现：
one\n
threetwo\n
因此
您必须说，文本文件是行和\n的交替，以行开始，以行结束
这真是一口，对吧？
你想要另一个奇怪的结果？
你必须接受一个空文件（0字节，实际上是0位）是一个单行文件，神奇的是，因为它们在微软很酷
这真是太疯狂了，你不觉得吗？
POSIX选择的后果是什么？
顶部的文件有点残缺，我们需要一些黑客来处理它。
是认真的
在前面的文本中，我是挑衅性的，因为处理缺少结尾的文本文件会迫使您使用特殊的滴答声/黑客来处理它们。你总是需要一个if/else来让事情运转起来，其中处理残缺行的分支只处理残缺行，所有其他行都采用另一个分支。这有点种族主义，不是吗？
我的结论
我赞成POSIX对行的定义，原因如下：
文件自然被认为是一系列行一行不应该是这样或那样的，这取决于它在文件中的位置空文件不是单行文件，拜托！您不应该被迫对代码进行黑客攻击
是的，Windows确实鼓励您省略后面的\r\n。如果需要下面的两行文件，则必须省略尾部，否则文本编辑器会将其显示为三行文件：
