意想不到的T_IF 意想不到的T_ELSEIF 意想不到的T_ELSE 意想不到的T_ENDIF

条件控件块if、elseif和else遵循一个简单的结构。当你遇到语法错误时，很可能只是无效的块嵌套→缺少{花括号}——或者多了一个。

Missing { or } due to incorrect indentation Mismatched code braces are common to less well-formatted code such as: if((!($opt["uniQartz5.8"]!=$this->check58)) or (empty($_POST['poree']))) {if ($true) {echo"halp";} elseif((!$z)or%b){excSmthng(False,5.8)}elseif (False){ If your code looks like this, start afresh! Otherwise it's unfixable to you or anyone else. There's no point in showcasing this on the internet to inquire for help. You will only be able to fix it, if you can visually follow the nested structure and relation of if/else conditionals and their { code blocks }. Use your IDE to see if they're all paired. if (true) { if (false) { … } elseif ($whatever) { if ($something2) { … } else { … } } else { … } if (false) { // a second `if` tree … } else { … } } elseif (false) { … } Any double } } will not just close a branch, but a previous condition structure. Therefore stick with one coding style; don't mix and match in nested if/else trees. Apart from consistency here, it turns out helpful to avoid lengthy conditions too. Use temporary variables or functions to avoid unreadable if-expressions. IF cannot be used in expressions A surprisingly frequent newcomer mistake is trying to use an if statement in an expression, such as a print statement: ⇓ echo "<a href='" . if ($link == "example.org") { echo … Which is invalid of course. You can use a ternary conditional, but beware of readability impacts. echo "<a href='" . ($link ? "http://yes" : "http://no") . "</a>"; Otherwise break such output constructs up: use multiple ifs and echos. Better yet, use temporary variables, and place your conditionals before: if ($link) { $href = "yes"; } else { $href = "no"; } echo "<a href='$href'>Link</a>"; Defining functions or methods for such cases often makes sense too. Control blocks don't return "results" Now this is less common, but a few coders even try to treat if as if it could return a result: $var = if ($x == $y) { "true" }; Which is structurally identical to using if within a string concatenation / expression. But control structures (if / foreach / while) don't have a "result". The literal string "true" would also just be a void statement. You'll have to use an assignment in the code block: if ($x == $y) { $var = "true"; } Alternatively, resort to a ?: ternary comparison. If in If You cannot nest an if within a condition either: ⇓ if ($x == true and (if $y != false)) { ... } Which is obviously redundant, because the and (or or) already allows chaining comparisons. Forgotten ; semicolons Once more: Each control block needs to be a statement. If the previous code piece isn't terminated by a semicolon, then that's a guaranteed syntax error: ⇓ $var = 1 + 2 + 3 if (true) { … } Btw, the last line in a {…} code block needs a semicolon too. Semicolon too early Now it's probably wrong to blame a particular coding style, as this pitfall is too easy to overlook: ⇓ if ($x == 5); { $y = 7; } else ← { $x = -1; } Which happens more often than you might imagine. When you terminate the if () expression with ; it will execute a void statement. The ; becomes a an empty {} of its own! The {…} block thus is detached from the if, and would always run. So the else no longer had a relation to an open if construct, which is why this would lead to an Unexpected T_ELSE syntax error. Which also explains a likewise subtle variation of this syntax error: if ($x) { x_is_true(); }; else { something_else(); }; Where the ; after the code block {…} terminates the whole if construct, severing the else branch syntactically. Not using code blocks It's syntactically allowed to omit curly braces {…} for code blocks in if/elseif/else branches. Which sadly is a syntax style very common to unversed coders. (Under the false assumption this was quicker to type or read). However that's highly likely to trip up the syntax. Sooner or later additional statements will find their way into the if/else branches: if (true) $x = 5; elseif (false) $x = 6; $y = 7; ← else $z = 0; But to actually use code blocks, you do have to write {…} them as such! Even seasoned programmers avoid this braceless syntax, or at least understand it as an exceptional exception to the rule. Else / Elseif in wrong order One thing to remind yourself is the conditional order, of course. if ($a) { … } else { … } elseif ($b) { … } ↑ You can have as many elseifs as you want, but else has to go last. That's just how it is. Class declarations As mentioned above, you can't have control statements in a class declaration: class xyz { if (true) { function ($var) {} } You either forgot a function definition, or closed one } too early in such cases. Unexpected T_ELSEIF / T_ELSE When mixing PHP and HTML, the closing } for an if/elseif must be in the same PHP block <?php ?> as the next elseif/else. This will generate an error as the closing } for the if needs to be part of the elseif: <?php if ($x) { ?> html <?php } ?> <?php elseif ($y) { ?> html <?php } ?> The correct form <?php } elseif: <?php if ($x) { ?> html <?php } elseif ($y) { ?> html <?php } ?> This is more or less a variation of incorrect indentation - presumably often based on wrong coding intentions. You cannot mash other statements inbetween if and elseif/else structural tokens: if (true) { } echo "in between"; ← elseif (false) { } ?> text <?php ← else { } Either can only occur in {…} code blocks, not in between control structure tokens. This wouldn't make sense anyway. It's not like that there was some "undefined" state when PHP jumps between if and else branches. You'll have to make up your mind where print statements belong to / or if they need to be repeated in both branches. Nor can you part an if/else between different control structures: foreach ($array as $i) { if ($i) { … } } else { … } There is no syntactic relation between the if and else. The foreach lexical scope ends at }, so there's no point for the if structure to continue. T_ENDIF If an unexpected T_ENDIF is complained about, you're using the alternative syntax style if: ⋯ elseif: ⋯ else: ⋯ endif;. Which you should really think twice about. A common pitfall is confusing the eerily similar : colon for a ; semicolon. (Covered in "Semicolon too early") As indentation is harder to track in template files, the more when using the alternative syntax - it's plausible your endif; does not match any if:. Using } endif; is a doubled if-terminator. While an "unexpected $end" is usually the price for a forgotten closing } curly brace. Assignment vs. comparison So, this is not a syntax error, but worth mentioning in this context: ⇓ if ($x = true) { } else { do_false(); } That's not a ==/=== comparison, but an = assignment. This is rather subtle, and will easily lead some users to helplessly edit whole condition blocks. Watch out for unintended assignments first - whenver you experience a logic fault / misbeheviour.

意想不到的“。”

如果您试图在不受支持的PHP版本中使用splat操作符(…)，就会发生这种情况。

．.． 首次在PHP 5.6中可用来捕获函数的可变数量的参数:

function concatenate($transform, ...$strings) {
    $string = '';
    foreach($strings as $piece) {
        $string .= $piece;
    }
    return($transform($string));
}

echo concatenate("strtoupper", "I'd ", "like ", 4 + 2, " apples");
// This would print:
// I'D LIKE 6 APPLES

在PHP 7.4中，可以将它用于Array表达式。

$parts = ['apple', 'pear'];
$fruits = ['banana', 'orange', ...$parts, 'watermelon'];
// ['banana', 'orange', 'apple', 'pear', 'watermelon'];

意想不到的美元结束

当PHP谈到“意外的$end”时，这意味着您的代码在解析器期望更多代码时结束了。(如果从字面上理解，这个信息有点误导。它不是关于一个名为“$end”的变量，就像新来者有时认为的那样。它指的是“文件的结束”，EOF。)

原因:代码块/和函数或类声明的{和}不平衡。

它几乎总是缺少一个}花括号来关闭前面的代码块。它的意思是，解析器希望找到一个结束}，但实际上到达了文件的末尾。

同样，使用适当的缩进来避免此类问题。 使用带有括号匹配的IDE，找出}错误的地方。 在大多数ide和文本编辑器中都有快捷键: NetBeans, PhpStorm, Komodo: Ctrl[和Ctrl] Eclipse, Aptana: CtrlShiftP Atom, Sublime: Ctrlm - Zend Studio Ctrlm Geany, notepad++: CtrlB - Joe: CtrlG - Emacs: C-M-n - Vim: %

大多数ide还突出显示匹配的大括号、方括号和圆括号。 这使得检查它们的相关性变得非常容易:

无端接的表达式

对于未结束的表达式或语句，也会出现意外的$end语法/解析器错误:

$var = func（1， ？>EOF

因此，首先查看脚本的末尾。拖尾;在任何PHP脚本中，最后一条语句通常是多余的。但你应该有一个。正是因为它缩小了这些语法问题的范围。特别是在您发现自己在脚本末尾添加了更多语句之后。

缩进的HEREDOC标记

另一种常见情况出现在HEREDOC或NOWDOC字符串中。如果前面有空格、制表符等，终止标记将被忽略:

print <<< END
    Content...
    Content....
  END;
# ↑ terminator isn't exactly at the line start

因此，解析器假定HEREDOC字符串将一直持续到文件的末尾(因此是“意外的$end”)。几乎所有的ide和语法高亮编辑器都会明确显示或发出警告。

转义的引号

如果你在字符串中使用\，它有一个特殊的含义。这称为“转义字符”，通常告诉解析器按字面意思取下一个字符。

示例:echo 'Jim said \'Hello\ ";将打印Jim说'hello'

如果转义字符串的结束引号，结束引号将被字面上理解，而不是像预期的那样，即作为字符串的一部分而不是结束字符串的可打印引号。这通常会在打开下一个字符串后或脚本结束时显示为解析错误。

在Windows中指定路径时非常常见的错误:“C:\xampp\htdocs\”是错误的。你需要“C:\\xampp\\htdocs\\ \”。另外，PHP通常会转换unix风格的路径(例如。“C:/xampp/htdocs/”)到Windows的正确路径。

替代语法

在模板中使用语句/代码块的替代语法时，很少会看到这种语法错误。使用if:和else:和一个缺失的endif;为例。

参见:

PHP语法错误“意外$end” 解析错误:语法错误，在我的PHP代码文件意外结束 解析错误语法错误文件意外结束，使用PHP PHP解析错误:语法错误，CodeIgniter视图中的文件意外结束 解析错误:语法错误，文件意外结束(注册脚本) “解析错误:语法错误，意外$end”为我的uni注册分配 修复PHP错误:PHP错误#3:文件意外结束

意想不到的“=”

这可能是由于在变量名中使用无效字符造成的。变量名称必须遵循以下规则:

变量名与PHP中的其他标签遵循相同的规则。有效变量名以字母或下划线开头，后面跟着任意数量的字母、数字或下划线。作为正则表达式，它可以这样表示:'[a- za - z_ \x7f-\xff][a- za - z0 -9_\x7f-\xff]*'

语法错误是什么?

PHP属于c风格的命令式编程语言。它有严格的语法规则，当遇到错位的符号或标识符时，它无法恢复。它无法猜测你的编码意图。

最重要的建议

这里有一些你总是可以采取的基本预防措施:

使用适当的代码缩进，或采用任何高级的编码风格。 可读性可以防止不规则性。 使用带有语法高亮显示功能的IDE或PHP编辑器。 这也有助于括号/方括号平衡。 阅读手册中的语言参考和示例。 两次，达到一定程度的熟练。

如何解释解析器错误

典型的语法错误消息如下:

解析错误:语法错误，意外的T_STRING，期望在file.php第217行有';

它列出了语法错误的可能位置。请参阅提到的文件名和行号。

像T_STRING这样的别名解释了解析器/标记器最终不能处理哪个符号。然而，这并不一定是语法错误的原因。

查看之前的代码行也很重要。通常语法错误只是之前发生的意外。错误行号只是解析器最终放弃处理的地方。

解决语法错误

有许多方法可以缩小和修复语法问题。

Open the mentioned source file. Look at the mentioned code line. For runaway strings and misplaced operators, this is usually where you find the culprit. Read the line left to right and imagine what each symbol does. More regularly you need to look at preceding lines as well. In particular, missing ; semicolons are missing at the previous line ends/statement. (At least from the stylistic viewpoint. ) If { code blocks } are incorrectly closed or nested, you may need to investigate even further up the source code. Use proper code indentation to simplify that. Look at the syntax colorization! Strings and variables and constants should all have different colors. Operators +-*/. should be tinted distinct as well. Else they might be in the wrong context. If you see string colorization extend too far or too short, then you have found an unescaped or missing closing " or ' string marker. Having two same-colored punctuation characters next to each other can also mean trouble. Usually, operators are lone if it's not ++, --, or parentheses following an operator. Two strings/identifiers directly following each other are incorrect in most contexts. Whitespace is your friend. Follow any coding style. Break up long lines temporarily. You can freely add newlines between operators or constants and strings. The parser will then concretize the line number for parsing errors. Instead of looking at the very lengthy code, you can isolate the missing or misplaced syntax symbol. Split up complex if statements into distinct or nested if conditions. Instead of lengthy math formulas or logic chains, use temporary variables to simplify the code. (More readable = fewer errors.) Add newlines between: The code you can easily identify as correct, The parts you're unsure about, And the lines which the parser complains about. Partitioning up long code blocks really helps to locate the origin of syntax errors. Comment out offending code. If you can't isolate the problem source, start to comment out (and thus temporarily remove) blocks of code. As soon as you got rid of the parsing error, you have found the problem source. Look more closely there. Sometimes you want to temporarily remove complete function/method blocks. (In case of unmatched curly braces and wrongly indented code.) When you can't resolve the syntax issue, try to rewrite the commented out sections from scratch. As a newcomer, avoid some of the confusing syntax constructs. The ternary ? : condition operator can compact code and is useful indeed. But it doesn't aid readability in all cases. Prefer plain if statements while unversed. PHP's alternative syntax (if:/elseif:/endif;) is common for templates, but arguably less easy to follow than normal { code } blocks. The most prevalent newcomer mistakes are: Missing semicolons ; for terminating statements/lines. Mismatched string quotes for " or ' and unescaped quotes within. Forgotten operators, in particular for the string . concatenation. Unbalanced ( parentheses ). Count them in the reported line. Are there an equal number of them? Don't forget that solving one syntax problem can uncover the next. If you make one issue go away, but other crops up in some code below, you're mostly on the right path. If after editing a new syntax error crops up in the same line, then your attempted change was possibly a failure. (Not always though.) Restore a backup of previously working code, if you can't fix it. Adopt a source code versioning system. You can always view a diff of the broken and last working version. Which might be enlightening as to what the syntax problem is. Invisible stray Unicode characters: In some cases, you need to use a hexeditor or different editor/viewer on your source. Some problems cannot be found just from looking at your code. Try grep --color -P -n "\[\x80-\xFF\]" file.php as the first measure to find non-ASCII symbols. In particular BOMs, zero-width spaces, or non-breaking spaces, and smart quotes regularly can find their way into the source code. Take care of which type of linebreaks are saved in files. PHP just honors \n newlines, not \r carriage returns. Which is occasionally an issue for MacOS users (even on OS  X for misconfigured editors). It often only surfaces as an issue when single-line // or # comments are used. Multiline /*...*/ comments do seldom disturb the parser when linebreaks get ignored. If your syntax error does not transmit over the web: It happens that you have a syntax error on your machine. But posting the very same file online does not exhibit it anymore. Which can only mean one of two things: You are looking at the wrong file! Or your code contained invisible stray Unicode (see above). You can easily find out: Just copy your code back from the web form into your text editor. Check your PHP version. Not all syntax constructs are available on every server. php -v for the command line interpreter <?php phpinfo(); for the one invoked through the webserver. Those aren't necessarily the same. In particular when working with frameworks, you will them to match up. Don't use PHP's reserved keywords as identifiers for functions/methods, classes or constants. Trial-and-error is your last resort.

如果所有这些都失败了，您总是可以谷歌您的错误消息。语法符号不那么容易搜索(Stack Overflow本身是由SymbolHound索引的)。因此，在你找到相关的东西之前，可能需要多看几页。

进一步指导:

PHP调试基础:David Sklar 修正PHP错误Jason McCreary PHP错误- Mario Lurig的10个常见错误 常见的PHP错误和解决方案 如何解决和修复你的WordPress网站 给设计师的PHP错误信息指南-粉碎杂志

白屏死机

如果你的网站是空白的，那么通常是语法错误造成的。 使用以下方法启用其显示:

error_reporting = E_ALL Display_errors = 1

在你的php.ini中，或者mod_php的。htaccess中， 甚至是带有FastCGI设置的。user.ini。

在破碎的脚本中启用它太晚了，因为PHP甚至不能解释/运行第一行。一个快速的解决方法是创建一个包装器脚本，比如test.php:

<?php
   error_reporting(E_ALL);
   ini_set("display_errors", 1);
   include("./broken-script.php");

然后通过访问这个包装器脚本调用失败的代码。

它还有助于启用PHP的error_log，并在脚本因HTTP 500响应而崩溃时查看web服务器的error.log。

意想不到的:

1. PHP 8命名参数语法

Unexpected ':'， expected '，' or ')'

如果试图在PHP < 8的版本中使用PHP 8的新命名形参功能，将会出现以下错误:

$table->string(column:'Name');

解决方案:

将PHP版本升级到PHP 8.0.0或更高版本 不要使用命名参数(按照预期的顺序传递参数)

2. 裁剪类::分隔符

以“解析错误:语法错误，意外的‘:’”开头的错误消息可能是由于错误地将类静态引用class::$Variable写成class:$Variable而引起的。