“是否有其他好的理由(除了标题问题)跳过结束php标记?”

在生成二进制输出、CSV数据或其他非html输出时，您不希望无意中输出无关的空白字符。

这不是标签……

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

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

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

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

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

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

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是有效的(不是语法错误)，正如@David Dorward所说，它允许避免在?>后面有空格/换行符(任何可以向浏览器发送头信息的东西)。

例如,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

无效。

But

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

会的。

就这一次，为了安全，你必须偷懒。

嗯，有两种方式来看待它。

PHP代码只不过是一组XML处理指令，因此任何具有. PHP扩展名的文件都只不过是一个恰好被解析为PHP代码的XML文件。 PHP恰好为它的打开和关闭标记共享XML处理指令格式。基于此，扩展名为.php的文件可能是有效的XML文件，但它们不一定是。

如果您相信第一种方法，那么所有PHP文件都需要结束标记。省略它们将创建一个无效的XML文件。然后，没有开口<?xml version="1.0" charset="latin-1" ?>声明，你将不会有一个有效的xml文件…所以这不是一个大问题……

如果你相信第二种方法，那么就会出现两种类型的.php文件:

只包含代码的文件(例如库文件) 包含原生XML和代码的文件(例如模板文件)

基于此，只有代码的文件可以在没有?>结束标记的情况下结束。但是XML代码文件不使用?>结束是不合适的，因为它会使XML无效。

但我知道你在想什么。你会想，这有什么关系，你永远不会直接呈现PHP文件，所以谁会关心它是否是有效的XML。如果您正在设计一个模板，那么这确实很重要。如果它是有效的XML/HTML，普通浏览器将不会显示PHP代码(它被视为注释)。所以你可以模拟出模板，而不需要运行PHP代码…

我不是说这很重要。这只是一个我不经常看到的观点，所以还有什么更好的地方来分享它呢?

就我个人而言，我不关闭库文件中的标签，但在模板文件中这样做…我认为这是基于个人喜好(和编码指南)的。