Composer实际使用的PHP版本由shell中php命令决定，与php -v不一致通常是PATH未刷新或config.platform.php配置干扰所致；需通过which php和composer show --platform排查，并确保环境与配置统一。
php -v 显示的版本和 Composer 实际用的不一致
这几乎总是 PATH 或 shell 环境没刷新导致的。Composer 不自己选 PHP，它直接调用 php 命令——所以 php -v 输出什么，它就信什么。但你可能刚切了版本（比如用 brew link php@8.2），却忘了新开终端，或者 IDE 内置终端没 reload。
验证方式很简单：
which php<br>php -v
这两行必须在同一个 shell 里执行，且输出路径要和 php -v 版本对得上。如果 which php 返回 /usr/bin/php，但 php -v 显示 8.2，说明系统 PATH 里有软链或 alias 干扰，得查 alias php 和 echo $PATH。
composer install 报错 requires php ^8.1，但 php -v 是 8.2
这时大概率是 config.platform.php 在作祟。Composer 会优先读这个配置，而不是真实环境。运行 composer show --platform 看它“认为”的 PHP 版本是多少。如果输出是 php: 7.4.33，哪怕你本地是 8.2，它也会按 7.4 解析依赖。
检查 composer.json 里有没有类似这样的块：
"config": {<br> "platform": {<br> "php": "7.4.33"<br> }<br>}
有就删掉，或者改成匹配你真实版本的值（如 "php": "8.2.10"）。改完必须跑 composer update --lock，否则 composer.lock 还记着旧平台信息。
想用 PHP 8.1 装 Laravel 11，但本地只有 PHP 8.0
Laravel 11 要求 PHP >=8.2，这不是 Composer “卡你”，而是它的核心类用了 readonly、命名参数等语法，PHP 8.0 根本解析不了。此时绕不过去：
-
--ignore-platform-req=php只让composer install成功，vendor 里照样塞进 Laravel 11 的代码，一运行就ParseError: syntax error, unexpected token "readonly" - 降级 Laravel 不现实——Laravel 10 已 EOL，安全更新都没了
- 唯一靠谱路径：升级本地 PHP 到 8.2+。Ubuntu 用
ondrej/php源，macOS 用brew install php@8.2，Windows 下载官方二进制或换 XAMPP 8.2+
别指望靠 config.platform.php “假装”有 8.2——那只是骗过依赖解析，骗不过 PHP 解释器本身。
CI/CD 流水线里 PHP 版本总对不上
CI 环境里最常踩的坑是没显式声明 PHP 版本，结果默认用了系统自带的旧版（比如 Ubuntu 22.04 自带 PHP 8.1，但项目要 8.2）。更糟的是，有些镜像把 php 命令软链到 php8.1，但没装 php8.2 包。
解决办法很直白：
- 在 CI 脚本开头加
php -v打日志，确认 CLI 版本 - 用完整路径调用 Composer：
/usr/bin/php8.2 /usr/local/bin/composer install，彻底避开 PATH 干扰 - 不要依赖全局
composer命令，改用php composer.phar install，并确保composer.phar是你下载的指定版本（CI 中推荐固定COMPOSER_VERSION=2.5.8）
真正麻烦的不是版本切换，而是团队成员各自环境不统一——有人用 Valet，有人用 Docker，有人直接装系统 PHP。一旦 config.platform.php 被提交进仓库，就等于把“假设环境”硬编码进了项目，后续谁都难改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
