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

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*)$替换为空文本。

这不是标签……

但如果你有了它，你就有可能在它后面留下空白。

如果你把它作为一个包含在文档的顶部，你可能会在你试图发送HTTP头之前插入空白(即内容)，这是不允许的。

这是一个新手编码风格的建议，出于善意，并由手册建议。

Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems. PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?>. Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.) Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag. There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>\n and the more recent ones (PSR-2) agreeing on omission. (For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs). SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.

不鼓励使用?>结束标记只是延迟解释基本的PHP处理行为和语言语义，以避免不常见的问题。由于参与者的熟练程度不同，它对于协作软件开发仍然是实用的。

关闭标签的变化

The regular ?> close tag is also known as T_CLOSE_TAG, or thus "close token". It comprises a few more incarnations, because of PHPs magic newline eating: ?>\n (Unix linefeed) ?>\r (Carriage return, classic MACs) ?>\r\n (CR/LF, on DOS/Win) PHP doesn't support the Unicode combo linebreak NEL (U+0085) however. Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance. Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token. The "hard close tag" isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token. __HALT_COMPILER(); ?> Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted. Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective. Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens: Simple spacing // ? > to evade detection by PHPs tokenizer. Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp. Both mean nothing to PHP, but can have practical uses for PHP-unaware or semi-aware external toolkits. Again cat-joined scripts come to mind, with resulting // ? > <?php concatenations that inline-retain the former file sectioning.

因此，对于强制的关闭标记省略，有依赖于上下文但实用的替代方法。

手动照看?>结束标记也不是很现代。一直都有自动化工具(即使只有sed/awk或regex-oneliners)。特别是:

Phptags标签更整洁 https://fossil.include-once.org/phptags/

通常可以用来为第三方代码打开php标签，或者只是修复任何(和所有)实际的空白/BOM问题:

Phptags——warn——whitespace *.php

它还处理——长标签转换等运行时/配置兼容性。

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)

Pros

像其他语言一样，关闭任何打开的标记是合乎逻辑的。不仅是X(HT)ML标签，还有花括号，括号… 对初学者来说更容易理解。

Cons

避免在结束标记后无意中添加空白，因为它破坏了header()函数的行为…一些编辑器或FTP客户端/服务器也会自动更改文件的结尾(至少，这是它们的默认配置) PHP手册说关闭标记是可选的，Zend甚至禁止它。

结论

我想说，支持省略标记的论点看起来更强(有助于避免header() +它是PHP/Zend的“推荐”)。我承认，就语法一致性而言，这不是我见过的最“漂亮”的解决方案，但还有什么更好的呢?