我刚刚在输出到Windows客户端时遇到了这个问题。当然，PHP_EOL是针对服务器端的，但是php的大部分内容输出都是针对windows客户端的。所以我必须把我的发现放在这里给下一个人看。

A)呼应“我的短信”。PHP_EOL;//不好，因为这只是输出\n，大多数版本的windows记事本显示在一行上，大多数windows会计软件不能导入这种类型的行结束字符。

B)回复“My Text \r\n”;//不好，因为单引号php字符串不解释\r\n

C)回复“My Text \r\n”;//太棒了!在记事本中看起来正确，并在将文件导入到其他windows软件(如windows会计和windows制造软件)时工作。

我刚刚在输出到Windows客户端时遇到了这个问题。当然，PHP_EOL是针对服务器端的，但是php的大部分内容输出都是针对windows客户端的。所以我必须把我的发现放在这里给下一个人看。

A)呼应“我的短信”。PHP_EOL;//不好，因为这只是输出\n，大多数版本的windows记事本显示在一行上，大多数windows会计软件不能导入这种类型的行结束字符。

B)回复“My Text \r\n”;//不好，因为单引号php字符串不解释\r\n

C)回复“My Text \r\n”;//太棒了!在记事本中看起来正确，并在将文件导入到其他windows软件(如windows会计和windows制造软件)时工作。

我有一个站点，其中一个日志脚本在用户的操作之后向文本文件写入新一行文本，用户可以使用任何操作系统。

在这种情况下，使用PHP_EOL似乎不是最优的。如果用户是在Mac OS上，并写入文本文件，它将放置\n。当在windows计算机上打开文本文件时，它不会显示换行符。因此，我使用“\r\n”来代替在任何操作系统上打开文件时的工作。

我在必须编写的一些命令行脚本中使用PHP_EOL常量。我在本地Windows机器上进行开发，然后在Linux服务器上进行测试。使用常量意味着我不必担心为每个不同的平台使用正确的行尾。

我想提出一个解决“什么时候不使用它”的答案，因为它还没有被覆盖，可以想象它被盲目地使用，直到后来才有人注意到有问题。这与现有的答案有些矛盾。

如果在HTML中输出到网页，特别是<textarea>， <pre>或<code>中的文本，您可能总是想使用\n而不是PHP_EOL。

原因是，虽然代码可能在一台服务器上工作得很好-这恰好是一个类unix平台-如果部署在Windows主机(如Windows Azure平台)上，那么它可能会改变页面在某些浏览器(特别是Internet Explorer -某些版本将看到\n和\r)中的显示方式。

我不确定自IE6以来这是否仍然是一个问题，所以它可能是相当有争议的，但似乎值得一提，如果它有助于人们思考上下文。在其他情况下(比如严格的XHTML)，在某些平台上突然输出\r可能会导致输出出现问题，我相信还有其他类似的边缘情况。

有人已经指出，当返回HTTP报头时，你不会想要使用它——因为它们在任何平台上都应该始终遵循RFC。

我不会将它用于CSV文件上的分隔符之类的东西(就像有人建议的那样)。服务器运行的平台不应该决定生成或使用的文件中的行结束符。

我更喜欢用\n\r。而且我在windows系统上，\n在我的经验中工作得很好。

由于PHP_EOL不能与正则表达式一起工作，而正则表达式是处理文本的最有用的方法，所以我真的从未使用过它，也不需要使用它。