嗯，我知道原因，但我不能说出来:

对于只包含PHP代码的文件，永远不会出现结束标记(?>) 允许的。PHP并不要求它， 省略它可以防止 意外注入尾白 空格变成响应。

来源:http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

根据文档，如果关闭标记位于文件末尾，出于以下原因，最好省略它:

如果文件是纯PHP代码，最好省略文件末尾的PHP结束标记。这可以防止在PHP结束标记之后意外地添加空白或新行，这可能会导致不必要的影响，因为当程序员在脚本中不打算发送任何输出时，PHP将启动输出缓冲。

PHP手册>语言参考>基本语法> PHP标签

由于我的问题被标记为这个问题的重复，我认为可以发布为什么不省略结束标签?>可能是出于某些原因。

具有完整的处理指令语法(<?php……?>) PHP源代码是有效的SGML文档，可以用SGML解析器毫无问题地解析和处理。在附加的限制下，它也可以是有效的XML/XHTML。

没有什么可以阻止您编写有效的XML/HTML/SGML代码。PHP文档意识到了这一点。摘录:

注意:还要注意，如果要在XML或XHTML中嵌入PHP，则需要使用< ? PHP ?>标记以保持与标准兼容。

当然，PHP语法不是严格的SGML/XML/HTML，您创建的文档不是SGML/XML/HTML，就像您可以将HTML转换为XHTML以符合XML或不符合XML一样。

At some point you may want to concatenate sources. This will be not as easy as simply doing cat source1.php source2.php if you have inconsistency introduced by omitting closing ?> tags. Without ?> it's harder to tell if document was left in PHP escape mode or PHP ignore mode (PI tag <?php may have been opened or not). Life is easier if you consistently leave your documents in PHP ignore mode. It's just like work with well formatted HTML documents compared to documents with unclosed, badly nested tags etc. It seems that some editors like Dreamweaver may have problems with PI left open [1].

php代码有两种可能的用法:

PHP代码，如类定义或函数定义 使用PHP作为模板语言(例如在视图中)

在情形1中。关闭标签是完全没用的，我也想看到只有1(一个)php打开标签和NO(零)关闭标签在这种情况下。这是一个很好的实践，因为它使代码清晰，并将逻辑与表示分开。 对于表示情况(2.)，有些人发现关闭所有标签(甚至是PHP处理的标签)是很自然的，这导致了混乱，因为PHP实际上有2个独立的用例，不应该混合在一起:逻辑/微积分和表示

除了已经说过的所有内容之外，我还将提出另一个原因，这对我们的调试来说是一个巨大的痛苦。

Apache 2.4.6和php5.4实际上在我们的生产机器上，当关闭PHP标记后面有空白时，分割错误。我只是浪费了好几个小时，直到我终于用strace缩小了虫子的范围。

下面是Apache抛出的错误:

[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)

比正常进程更早地发送头文件可能会产生深远的后果。下面是我当时碰巧想到的其中一些:

While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately. You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution. You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago. If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with). Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.

额外的:一些与这两个角色有关的陷阱(实际上目前只有一个):

甚至一些知名的库可能在?>之后包含多余的行尾。一个例子是Smarty，甚至是这两个版本的最新版本。*和3。*分支有这个。因此，与往常一样，要注意第三方代码。额外的奖励:一个用于删除不必要的PHP结尾的正则表达式:在所有包含PHP代码的文件中将(\s*\?>\s*)$替换为空文本。