parse error 的真正原因常是前置语法错误（如缺分号、括号未闭合、引号不匹配），而非报错行本身；错误行号多为误导，解析器实际在迷路后将首个合法 token 误判为“unexpected”。
绝大多数 Parse error: syntax error 都不是“语法真错了”，而是 PHP 解析器在某个地方卡住后，把后面第一个合法词法单元（比如函数名、变量名、数字）当成了“意外出现的东西”。错误行号常是假象，真正问题往往在它前面几行。
为什么报错行看起来很无辜？
PHP 是逐字符扫描代码的。一旦某处少了个分号、括号没闭合、引号没配对，解析器就会一路错下去，直到遇到一个它完全无法解释的 token——比如 file_put_contents、echo、0 或 $。这时它报的“unexpected '0'”或“unexpected '$'”，其实是它迷路后撞上的第一堵墙，不是肇事点。
- 错误提示里的
unexpected T_ENDWHILE，大概率是前面漏了}或;，不是endwhile本身有问题 -
unexpected '?'通常说明你用了 PHP 7.0+ 的空合并操作符??，但服务器实际运行的是 PHP 5.6 或更低版本 -
unexpected end of file几乎总是因为：少了一个}、少了一个;、字符串里嵌了未转义的"或'、或者忘了写?>（尤其混用短标签时）
字符串里嵌 HTML/JS 就容易崩？
是的。双引号字符串里直接写 href="https://www.php.cn/link/a9c23f67c5dae361ac62c23c9be9473a"，PHP 会把第一个 " 当作字符串结束，后面就全乱套了。这不是逻辑错，是解析器提前收工了。
- 用单引号包裹整个字符串：
$html = '@#@#@#@#@#@#@#@#@#@0'; - 用双引号时转义内部引号：
$html = "href=\"https://www.php.cn/link/a9c23f67c5dae361ac62c23c9be9473a\""; - 复杂内容优先用
HEREDOC：$html = - 别在字符串里拼接 JS 变量，尤其是含
$的，极易触发unexpected '$'
访问 JSON 数组下标为什么报 unexpected '0'？
因为写了 $obj->descriptions->0->name。PHP 对象属性名不能以数字开头，->0 不合法。而 json_decode($json) 默认把 JSON 数组转成 PHP 索引数组，不是对象属性。
- 确认结构：
var_dump($decodedData->descriptions);看它到底是对象还是数组 - 如果是数组（最常见），改用方括号：
$decodedData->descriptions[0]->name - 如果硬要对象访问，加第二个参数
true强制转数组：json_decode($json, true)，然后用$arr['descriptions'][0]['name'] - 别依赖 IDE 自动补全的
->0，那是错的
short_open_tag 关掉会导致 T_ENDWHILE 报错？
会。如果代码里用了 或 =，而 php.ini 中 short_open_tag = Off，PHP 就会把 后面所有内容当纯文本处理，直到遇到下一个 ?> —— 结果就是控制结构（while、if）的结束标签被忽略，最终报 unexpected T_ENDWHILE。
- 检查当前配置：
phpinfo();搜索short_open_tag - 临时修复：把所有
改成<?php，=改成<?php echo - 长期建议：禁用 short_open_tag，统一用标准标签，避免跨环境问题
真正棘手的不是错误信息本身，而是它永远不告诉你“缺了啥”，只说“这儿不对”。盯住报错行的前 5 行，逐个检查分号、括号、引号、标签闭合——90% 的 case 都藏在那里。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
