我认为这个话题讨论得太多了/太复杂了。使用IDE是完全避免任何语法错误的方法。我甚至会说，在没有IDE的情况下工作是不专业的。为什么?因为现代ide会在输入每个字符后检查语法。当您编写代码时，整行代码都变成红色，并且有一个很大的警告通知显示语法错误的确切类型和确切位置，那么绝对没有必要搜索其他解决方案。

使用语法检查IDE意味着:

您将(有效地)再也不会遇到语法错误，因为您在输入时就能看到它们。认真对待。

具有语法检查功能的优秀ide(它们都适用于Linux、Windows和Mac):

NetBeans(免费) PHPStorm [$199 USD] Eclipse与PHP插件[免费] Sublime [$80 USD](主要是一个文本编辑器，但可扩展的插件，如PHP语法分析器)

意外的T_CONSTANT_ENCAPSED_STRING意外的t_encapsed_and_空白

T_CONSTANT_ENCAPSED_STRING和T_ENCAPSED_AND_WHITESPACE是指带引号的“字符串”字面量。

它们在不同的上下文中使用，但语法问题非常相似。t_encaged…警告出现在双引号的字符串上下文中，而T_CONSTANT…字符串经常在普通PHP表达式或语句中出错。

Incorrect variable interpolation And it comes up most frequently for incorrect PHP variable interpolation: ⇓ ⇓ echo "Here comes a $wrong['array'] access"; Quoting arrays keys is a must in PHP context. But in double quoted strings (or HEREDOCs) this is a mistake. The parser complains about the contained single quoted 'string', because it usually expects a literal identifier / key there. More precisely it's valid to use PHP2-style simple syntax within double quotes for array references: echo "This is only $valid[here] ..."; Nested arrays or deeper object references however require the complex curly string expression syntax: echo "Use {$array['as_usual']} with curly syntax."; If unsure, this is commonly safer to use. It's often even considered more readable. And better IDEs actually use distinct syntax colorization for that. Missing concatenation If a string follows an expression, but lacks a concatenation or other operator, then you'll see PHP complain about the string literal: ⇓ print "Hello " . WORLD " !"; While it's obvious to you and me, PHP just can't guess that the string was meant to be appended there. Confusing string quote enclosures The same syntax error occurs when confounding string delimiters. A string started by a single ' or double " quote also ends with the same. ⇓ print "<a href="' . $link . '">click here</a>"; ⌞⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟⌞⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⌟ That example started with double quotes. But double quotes were also destined for the HTML attributes. The intended concatenation operator within however became interpreted as part of a second string in single quotes. Tip: Set your editor/IDE to use slightly distinct colorization for single and double quoted strings. (It also helps with application logic to prefer e.g. double quoted strings for textual output, and single quoted strings only for constant-like values.) This is a good example where you shouldn't break out of double quotes in the first place. Instead just use proper \" escapes for the HTML attributes´ quotes: print "<a href=\"{$link}\">click here</a>"; While this can also lead to syntax confusion, all better IDEs/editors again help by colorizing the escaped quotes differently. Missing opening quote Equivalently are forgotten opening "/' quotes a recipe for parser errors: ⇓ make_url(login', 'open'); Here the ', ' would become a string literal after a bareword, when obviously login was meant to be a string parameter. Array lists If you miss a , comma in an array creation block, the parser will see two consecutive strings: array( ⇓ "key" => "value" "next" => "....", ); Note that the last line may always contain an extra comma, but overlooking one in between is unforgivable. Which is hard to discover without syntax highlighting. Function parameter lists The same thing for function calls: ⇓ myfunc(123, "text", "and" "more") Runaway strings A common variation are quite simply forgotten string terminators: ⇓ mysql_evil("SELECT * FROM stuffs); print "'ok'"; ⇑ Here PHP complains about two string literals directly following each other. But the real cause is the unclosed previous string of course. HEREDOC indentation Prior PHP 7.3, the heredoc string end delimiter can't be prefixed with spaces: print <<< HTML <link..> HTML; ⇑ Solution: upgrade PHP or find a better hoster.

另请参阅

PHP中关联数组的插值(双引号字符串) 语法错误，意外的T_CONSTANT_ENCAPSED_STRING 语法错误，PHP中意外的T_CONSTANT_ENCAPSED_STRING SQL查询中出现意外的T_CONSTANT_ENCAPSED_STRING错误

意想不到的T_IS_EQUAL 意想不到的T_IS_GREATER_OR_EQUAL 意想不到的T_IS_IDENTICAL 意想不到的T_IS_NOT_EQUAL 意想不到的T_IS_NOT_IDENTICAL 意想不到的T_IS_SMALLER_OR_EQUAL 意想不到的< 意想不到的>

比较运算符，如==，>=，===，!=，<>，!==和<=或<和>，主要应该只在表达式中使用，例如if表达式。如果解析器抱怨它们，那么通常意味着它们周围的paren不正确或不匹配()。

Parens grouping In particular for if statements with multiple comparisons you must take care to correctly count opening and closing parenthesis: ⇓ if (($foo < 7) && $bar) > 5 || $baz < 9) { ... } ↑ Here the if condition here was already terminated by the ) Once your comparisons become sufficiently complex it often helps to split it up into multiple and nested if constructs rather. isset() mashed with comparing A common newcomer is pitfal is trying to combine isset() or empty() with comparisons: ⇓ if (empty($_POST["var"] == 1)) { Or even: ⇓ if (isset($variable !== "value")) { This doesn't make sense to PHP, because isset and empty are language constructs that only accept variable names. It doesn't make sense to compare the result either, because the output is only/already a boolean. Confusing >= greater-or-equal with => array operator Both operators look somewhat similar, so they sometimes get mixed up: ⇓ if ($var => 5) { ... } You only need to remember that this comparison operator is called "greater than or equal" to get it right. See also: If statement structure in PHP Nothing to compare against You also can't combine two comparisons if they pertain the same variable name: ⇓ if ($xyz > 5 and < 100) PHP can't deduce that you meant to compare the initial variable again. Expressions are usually paired according to operator precedence, so by the time the < is seen, there'd be only a boolean result left from the original variable. See also: unexpected T_IS_SMALLER_OR_EQUAL Comparison chains You can't compare against a variable with a row of operators: ⇓ $reult = (5 < $x < 10); This has to be broken up into two comparisons, each against $x. This is actually more a case of blacklisted expressions (due to equivalent operator associativity). It's syntactically valid in a few C-style languages, but PHP wouldn't interpret it as expected comparison chain either. Unexpected > Unexpected < The greater than > or less than < operators don't have a custom T_XXX tokenizer name. And while they can be misplaced like all they others, you more often see the parser complain about them for misquoted strings and mashed HTML: ⇓ print "<a href='z">Hello</a>"; ↑ This amounts to a string "<a href='z" being compared > to a literal constant Hello and then another < comparison. Or that's at least how PHP sees it. The actual cause and syntax mistake was the premature string " termination. It's also not possible to nest PHP start tags: <?php echo <?php my_func(); ?> ↑

参见:

php T_IS_NOT_EQUAL错误 语法错误，意外的T_IS_EQUAL 返回语句的语法错误 http://forums.phpfreaks.com/topic/96891-parse-error-syntax-error-unexpected-t-is-not-identical-expecting-or/

意想不到的“=”

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

变量名与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。

意想不到的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.