composer执行成功不代表代码能运行，根本原因是php版本约束与实际运行环境不匹配：如用--ignore-platform-req或config.platform.php伪装版本，导致装入兼容低版本的包，但代码含enum/match等高版本语法，运行时直接parseerror或fatal error。
Composer 执行成功不代表代码能跑，报 ParseError 或 Fatal error 的根本原因，往往是 PHP 版本约束和实际运行环境不匹配。
composer install 成功但运行时报 ParseError: syntax error, unexpected token "enum"
这说明 Composer 没拦住你，但它没义务替你校验运行时能力。常见于以下情况：
- 你用了
--ignore-platform-req=php或硬写了"platform": {"php": "7.4.33"}，让 Composer 降级选了支持 PHP 7.4 的包版本，但你自己代码里写了enum Status—— PHP 7.4 根本不认识这个语法 - 依赖包的某个小版本（比如
monolog/monolog v3.5.0）内部用了match表达式或只读属性（readonly），而你本地是 PHP 8.0 以下，解析阶段就崩 -
composer.json里"require": {"php": "^8.1"}是对的，但你用的是/usr/bin/php7.4启动脚本（比如在 CI 中写死路径），Composer 没参与，PHP 解释器直接报错
为什么 php -v 和实际执行脚本的 PHP 版本不一致
Composer 只管自己启动时用的 PHP，而你的应用可能由另一个 PHP 二进制文件执行。排查要点：
- 运行
php -v看 CLI 默认版本；再查你真正跑服务的命令，比如php artisan serve或php index.php，它调用的是否是同一个php - 用
which php和ls -l $(which php)确认符号链接指向；macOS 用户注意brew unlink php@7.4 && brew link php@8.2才算切换干净 - Web 服务器（Apache/Nginx）和 CLI 的
php.ini完全独立，php -i | grep "Configuration File"输出的路径必须和你预期一致 - 某些部署工具（如 Envoyer、Laravel Forge）会显式指定 PHP 路径，别只信
php -v，得看日志里实际执行的是哪个二进制
composer show --platform 显示的 PHP 版本和 php -v 不同
这是 config.platform.php 在起作用——它不是“修复”，而是“伪装”。后果很直接：
- 设成
"7.4.33"后，Composer 会去 Packagist 拉symfony/console v5.4（兼容 7.4），但如果你代码里用了Attribute，运行时照样Fatal error - 设成
"8.2.10"但本地其实是 PHP 7.4，Composer 会拉v6.4，结果一运行就ParseError: readonly - CI 脚本里如果没清掉旧的
config.platform.php，会导致不同环境行为不一致，极难复现
如何验证当前环境真能跑新语法
别靠猜，用最小代码实测：
- 新建一个
test.php，内容为<?php enum Status { case Active; } echo "ok";，然后用你实际跑项目的 PHP 命令执行：/usr/bin/php8.1 test.php - 检查扩展是否启用：
php -m | grep -E 'curl|json|mbstring'，有些包（如guzzlehttp/guzzle）在缺少ext-curl时不会报错，但运行时抛异常 - 若用 Docker，确认
Dockerfile中php -v和composer --version使用的是同一个基础镜像层，避免多阶段构建中 PHP 版本漂移
最常被忽略的一点：Composer 的 platform 配置只影响安装时的包选择逻辑，它既不改变 PHP 解释器能力，也不注入任何 polyfill。你以为绕过了约束，其实只是把爆雷时间从安装阶段推迟到了第一次 require 自动加载时。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
