如果您确定服务器将支持短标记，并且您的开发人员能够理解它，那么使用短标记是可以接受的。 许多服务器不支持它，许多开发人员在看过一次之后就会理解它。 我使用完整的标记来确保可移植性，因为它真的没有那么糟糕。

说了这么多，我的一个朋友说，为了支持其他标准化的asp样式标签，比如<%而不是<?，这是php.ini中称为asp_tags的设置。他的理由如下:

．.． 随意的约定应该是 标准化。也就是说，任何时候我们都可以 面对一系列的可能性 都是等价的，比如什么 奇怪的标点符号我们的编程 应该用语言来界定 我们应该选择一个标准 坚持下去。这样我们 减少所有人的学习曲线 语言(或者其他的东西 公约属于)。

听起来不错，但我不认为我们所有人都能在这件事上保持一致。与此同时，我将坚持使用完整的<?php。

如果您确定服务器将支持短标记，并且您的开发人员能够理解它，那么使用短标记是可以接受的。 许多服务器不支持它，许多开发人员在看过一次之后就会理解它。 我使用完整的标记来确保可移植性，因为它真的没有那么糟糕。

说了这么多，我的一个朋友说，为了支持其他标准化的asp样式标签，比如<%而不是<?，这是php.ini中称为asp_tags的设置。他的理由如下:

．.． 随意的约定应该是 标准化。也就是说，任何时候我们都可以 面对一系列的可能性 都是等价的，比如什么 奇怪的标点符号我们的编程 应该用语言来界定 我们应该选择一个标准 坚持下去。这样我们 减少所有人的学习曲线 语言(或者其他的东西 公约属于)。

听起来不错，但我不认为我们所有人都能在这件事上保持一致。与此同时，我将坚持使用完整的<?php。

恕我直言，使用短标签的人经常忘记转义他们所呼应的内容。如果有一个默认转义的模板引擎就好了。我相信Rob A写了一个快速的hack来避免在Zend框架应用程序中的短标签。如果您喜欢短标签，因为它使PHP更容易阅读。那么Smarty是不是一个更好的选择呢?

{$myString|escape}

在我看来，这比

<?= htmlspecialchars($myString) ?> 

让我们面对现实吧。没有短标记的PHP非常丑陋。

如果你无法访问php.ini，你可以在.htaccess文件中启用它们:

php_flag short_open_tag on

注意:从PHP 5.4开始，短标记<?=，现在总是可用。

有人会问使用短标签的意义是什么。

打字更快

MDCore说:

<？=比输入<?php echo

是的，它是。你不必在整个脚本中键入7个字符* X次。

然而，当一个脚本需要一个小时，或10个小时，或更多的时间来设计、开发和编写，那么在脚本的整个过程中，这几秒钟没有在这里和那里输入那7个字符的时间又有什么关系呢?

相比之下，如果短标签没有打开，或正在打开，但更新或有人更改ini文件/服务器配置，可能会导致一些核心或所有脚本无法工作，其他可能性。

您获得的小好处并不能抵消潜在问题的严重性，即您的站点无法工作，或者更糟，只有部分无法工作，因此需要解决的问题令人头痛。

更容易阅读

这取决于熟悉程度。 我总是看到并使用<?php echo。所以当<?=并不难读，只是我不熟悉，所以不容易读。

如果前端和后端开发人员分开(就像大多数公司一样)，那么前端开发人员是否会更熟悉这些模板?=等于“PHP打开标签和回声”? 我想说大多数人会觉得更合乎逻辑的答案更舒服。也就是说，一个明确的PHP打开标记然后发生了什么"echo" - <?php echo。

风险评估 问题=整个网站或核心脚本无法工作;

发生问题的可能性非常低+结果的严重程度非常高=高风险

结论

你可以在这里节省几秒钟，而不必输入几个字符，但为此冒了很大的风险，结果也可能会失去可读性。

前端或后端程序员熟悉<?=更容易理解<?php echo，因为它们是标准的php东西- standard <?PHP打开标签和众所周知的“echo”。 (即使是前端程序员也应该知道“echo”，否则他们根本不会在框架提供的任何代码上工作)。

然而相反的情况就不太可能发生了，有人不太可能从逻辑上推断出PHP短标记上的等号是“echo”。