PHP语法错误“unexpected ‘…’”主因是版本过低不支持新语法，需确认实际运行环境版本并检查display_errors配置、Composer autoload及SAPI差异。
PHP 文件报错 “Syntax error, unexpected ‘…’” 是版本太低
这类错误基本是用了高版本 PHP 的语法（比如箭头函数 fn()、属性初始化 public int $id = 0;、联合类型 string|int），但运行环境是 PHP 7.4 或更早。PHP 8.0 开始大量引入新语法，低版本解析器直接报错退出，不会尝试兼容。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
php -v确认当前 CLI 版本；网页环境查phpinfo()输出或托管平台控制台 - 检查代码中是否含
fn()、match表达式、??=、new Foo()构造器调用等 —— 这些在 PHP 7.4 及以下均不支持 - 若必须降级适配，把
fn($x) => $x * 2改成function($x) { return $x * 2; }；把string|null改成?string（PHP 7.1+ 支持）或干脆去掉类型声明 - 注意：PHP 7.2 已停止安全更新，硬要锁老版本需自行承担风险
php.ini 中 display_errors 关闭导致“白屏”，误判为版本问题
很多用户看到页面空白，第一反应是 PHP 版本不对，其实只是错误被静默吞掉了。尤其共享主机常默认关闭错误显示，而语法错误属于 Parse Error，在 display_errors = Off 时不会输出任何提示。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 临时加一段探针代码：
<?php error_reporting(E_ALL); ini_set('display_errors', '1'); echo "OK"; ?>，能显示 OK 就说明 PHP 解析器工作正常 - 检查
error_log配置项指向的文件路径，用tail -f /path/to/php_error.log实时看真实报错 - 若用 Nginx + PHP-FPM，还需确认
php_admin_value[log_errors] = on在 pool 配置里已启用
Composer autoload 冲突引发的“Class not found”，看似版本问题实为加载失败
升级 PHP 后运行 composer install 没报错，但访问时提示类不存在，常见原因是 vendor/autoload.php 加载了旧版 autoloader（比如 PHP 7.x 生成的 classmap），而新版本 PHP 对 trait 使用或命名空间解析更严格，导致跳过某些文件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 删掉
vendor/和composer.lock，重新执行composer install --no-cache - 检查
composer.json中"platform": {"php": "8.1.0"}是否与实际环境一致，不匹配会导致依赖安装错乱 - 运行
composer show php确认 Composer 认为的当前 PHP 版本，它可能读取的是 CLI 版本而非 FPM 版本
Apache mod_php 与 PHP-FPM 混用导致版本不一致
本地开发用 XAMPP（mod_php），上线用宝塔（PHP-FPM），两个模块加载的 PHP 配置文件（php.ini）路径不同，extension_dir、date.timezone 等差异会间接引发解析异常，比如扩展没加载成功，后续代码调用 json_encode() 却提示函数未定义。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在出问题的脚本开头加
var_dump(PHP_SAPI, PHP_VERSION, php_ini_loaded_file());，确认运行模式和配置来源 - mod_php 下
php.ini通常在/etc/php/7.4/apache2/php.ini，PHP-FPM 则多在/etc/php/7.4/fpm/php.ini—— 修改必须对应对 - 避免在 Apache vhost 里用
php_admin_flag覆盖关键设置，容易与 FPM pool 冲突
真正卡住的往往不是语法本身，而是多个环境层（CLI/FPM/SAPI/Composer/platform config）之间版本认知不一致。先定位哪一层在报错，再比对那一层的真实 PHP 版本和配置加载路径，比盲目升级或降级更省时间。
