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

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

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

如果我正确理解这个问题，它与输出缓冲以及这可能对结束/结束标记的影响有关。我不确定这是一个完全合理的问题。问题是输出缓冲区并不意味着所有内容在发送到客户机之前都保存在内存中。意思是有些内容是。

程序员可以故意刷新缓冲区或输出缓冲区那么PHP中的输出缓冲区选项真的会改变结束标记对编码的影响吗?我认为不是这样的。

也许这就是为什么大多数答案都回到了个人风格和语法。

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

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

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

应该去掉php结束标记(?>)的原因是，这样程序员就不会意外地发送额外的换行字符。

不应该省略php结束标记的原因是它会导致php标记的不平衡，任何稍微有点头脑的程序员都可以记住不要添加额外的空白。

对于你的问题

还有其他好的理由跳过结束php标记吗?

不，没有其他好的理由跳过结束php标记。

我将以不使用结束标签的一些理由来结束:

人们总是会犯错误，不管他们有多聪明。 坚持一种可以减少可能错误数量的做法(恕我直言)是一个好主意。 PHP不是XML。PHP不需要遵循xml的严格标准来编写良好并具有良好的功能。如果一个丢失的结束标签让你烦恼，你可以使用一个结束标签，这不是一个固定不变的规则。

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

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

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

Pros

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

Cons

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

结论

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