答案是composer install使用shell实际调用的php二进制文件，由which php路径决定，而非php -v显示版本或config.platform.php声明版本；需通过/usr/bin/php8.2 composer install等方式显式指定路径确保一致。
composer install 用的是哪个 PHP 版本？
不是你 php -v 看到的那个，也不是 composer.json 里 "platform": {"php": "8.2"} 声明的那个——而是你执行命令时，shell 实际调用的 php 二进制文件。这个路径由 which php 决定，而 composer 本身只是个 PHP 脚本，靠 shebang（比如 #!/usr/bin/env php）启动，完全受 $PATH 控制。
常见错误现象：php -v 显示 8.2，但 composer install 报错 “Your PHP version (7.4.33) does not satisfy that requirement”。说明 composer 启动时走的是另一个 php ——比如宝塔面板的 /www/server/php/74/bin/php，或 Windows 上 composer.bat 里硬编码的旧路径。
验证方式必须三步一起做：
-
php -v—— 看当前 shell 的 PHP 版本 -
which php—— 看它指向哪 -
php -r "echo PHP_BINARY;"—— 这才是 Composer 内部实际加载的解释器路径
Linux/macOS 下显式指定 PHP 8.2 运行 composer install
最稳、不依赖环境变量、CI 友好、多项目共存无冲突的方式：直接把 PHP 路径写在命令最前面。
示例（根据你的实际安装路径调整）：
- Ubuntu/Debian：
/usr/bin/php8.2 /usr/local/bin/composer install - macOS Homebrew：
/opt/homebrew/bin/php@8.2 /usr/local/bin/composer install - 宝塔面板：
/www/server/php/82/bin/php /usr/bin/composer install - 加参数优化：
/opt/homebrew/bin/php@8.2 -d memory_limit=-1 /usr/local/bin/composer install --optimize-autoloader（-d必须紧跟 PHP 路径后）
别用 alias composer='php8.2 composer' —— Git hooks、Makefile、非交互 shell 中会失效；也别改 update-alternatives 全局软链，容易影响其他项目。
Windows 下怎么确保 composer install 走 PHP 8.1？
Windows 用户最容易踩坑的地方是 composer.bat 文件。它通常第二行写着类似 @php "%~dp0composer.phar" %*，这里的 @php 就是关键：它调用的是 $PATH 里第一个 php.exe，而不是你双击 CMD 时看到的 php -v 结果。
安全做法只有两种：
- 临时指定完整路径：
"C:\php\php-8.1.25\php.exe" "C:\ProgramData\ComposerSetup\bin\composer.phar" install（路径必须加英文双引号） - 修改
composer.bat第二行，把@php换成绝对路径，如："C:\php\php-8.1.25\php.exe" "%~dp0composer.phar" %*
注意：composer self-update 不会重写 composer.bat，所以改完要手动测试是否生效。
config.platform.php 是干啥的？什么时候能用？
composer config platform.php "8.2.0" 只影响依赖解析阶段，即告诉 Composer：“请按 PHP 8.2 的能力去选包”，但它不改变运行时环境。生成的 vendor/autoload.php 和类文件，仍由你当前真实 PHP 版本编译和执行。
适用场景极少，且必须配合 composer update --lock：
- 你在 PHP 7.4 开发机上，要为 PHP 8.2 生产环境提前打包 vendor（CI 打包阶段）
- 团队统一声明目标平台，且所有依赖已验证兼容该版本
禁用场景更常见：
- 本地 PHP 是 7.4，却设
"platform": {"php": "8.2"}后直接跑 Laravel 11 ——代码里有match表达式，7.4 直接 parse error - 提交该配置到 git，队友没同步 PHP 版本，
composer install成功但运行时报错 - 以为设了 platform 就不用管实际 PHP 版本 ——这是混淆了“依赖解析”和“运行时执行”
真正复杂的地方在于：composer install 的校验、autoload 文件生成、scripts 执行、甚至 vendor/bin 下的二进制脚本，都可能各自绑定不同 PHP 版本。一个项目里混用多个 PHP 解释器，比想象中更容易出 silent failure。
