Composer为什么支持多版本PHP_Composer多环境切换【分享】

Composer为什么支持多版本PHP_Composer多环境切换【分享】

应明确指定目标PHP版本执行composer install，如Linux/macOS用/usr/bin/php8.1 composer install、Windows用"C:\php\8.1\php.exe" composer install，并确保php -v、which php和PHP_BINARY三者一致。

先说一个核心判断：Composer本身并不具备多版本PHP的支持能力，它本质上就是一个PHP脚本。你用什么版本的PHP去跑它，它就工作在哪个版本下。所谓的“多版本支持”，说白了就是手动控制调用哪个PHP解释器去执行Composer命令。

composer install 报 “PHP version does not satisfy requirement” 怎么办

问题不在Composer配置上，而是它正在用系统默认的php命令运行，而这个版本和composer.json里声明的"php": "^8.1"对不上。

• 先用php -v和which php确认当前生效的是哪个路径、哪个版本
• 别指望composer config platform.php能解决问题——它只影响依赖解析时的版本选择（“假装有8.1”），并不改变实际运行环境
• 临时解决其实就一条命令：/usr/bin/php8.1 /usr/local/bin/composer install（Linux/macOS）或"C:\php\8.1\php.exe" composer install（Windows）
• 如果你用的是Composer 2.2以上版本，COMPOSER_PHP环境变量是更干净的选择，比alias方式更优雅，而且不会干扰其他命令

为什么不能只靠config.platform.php

"config": {"platform": {"php": "8.1.0"}}这个配置，说白了就是在编译期“欺骗”依赖解析器：“请按PHP 8.1的标准来选包”。但仅限于install/update阶段有效，完全不影响运行时行为。

• 你在PHP 7.4环境下设置了platform.php = "8.2"，composer update确实能成功，但代码一跑就报ParseError: syntax error, unexpected token "match"
• CI用PHP 8.1构建，本地用8.3开发，光靠platform根本无法复现CI的依赖解析结果
• platform不检查扩展是否实际启用——"ext-mbstring": "*"写了等于没写；如果PHP 8.1本身没开mbstring，安装照样失败

怎么确认 Composer 实际用的是哪个 PHP 版本

别想当然地以为which php显示的路径就是Composer真正用的解释器——关键要看执行时实际调用了哪个。

• 很多系统里composer本身就是个shell脚本，开头写着#!/usr/bin/env php，最终调用的还是$PATH里第一个php
• 运行file $(which composer)，如果输出显示“shell script”，再跑head -n1 $(which composer)查看shebang行
• 更直接的方法是：运行php -r "echo PHP_BINARY;"，这个输出才是Composer内部真实调用的PHP二进制路径
• macOS Homebrew用户要特别注意：php@8.1安装后不会自动替换/usr/bin/php，php -v显示的很可能还是系统老版本

切换 PHP 版本后 vendor 目录必须重装

不同PHP版本下生成的vendor/目录不能混用，原因在于：

• PHP扩展可用性不同（比如ext-gd、ext-xml是否加载）
• 类加载逻辑差异（PHP 8.0+的联合类型、match表达式在低版本直接解析失败）
• 自动加载器缓存——vendor/autoload_static.php里硬编码了路径和类映射
• 某些插件或脚本（如phpunit、larastan）虽然放在autoload-dev下，运行时仍需对应PHP版本支持

最稳妥的做法始终是：切换PHP版本 → 删除vendor目录 → 用目标PHP版本显式执行composer install。