Composer不管理PHP版本，仅依赖shell中php命令指向的解释器；确认方式为执行php -v、which php和php -r "echo PHP_BINARY;"，最可靠切换是显式指定PHP路径运行（如/usr/bin/php8.2 composer.phar install），且切换后必须删除vendor和composer.lock并重装。
Composer 本身不管理 PHP 版本，它只是个 PHP 脚本，运行时完全依赖你 shell 中 php 命令指向的解释器。所谓“切换”，不是改 Composer 配置，而是确保它启动时用对的 PHP 二进制文件。
怎么确认 composer 实际用的是哪个 PHP？
很多人跳过这步就改配置，结果所有操作都白费。必须在执行 composer install 前立刻验证：
- 运行
php -v，看输出是否是你预期的版本（比如 PHP 8.2.15） - 运行
which php，确认路径是否匹配（比如/usr/bin/php8.2，而不是模糊的/usr/bin/php） - 运行
php -r "echo PHP_BINARY;"，这个才是 Composer 内部真实调用的二进制路径 - 如果
which composer返回的是 shell 脚本，再执行head -n1 $(which composer)，看 shebang 行是不是#!/usr/bin/env php——这个php就是关键
显式调用目标 PHP 是最稳方案
不依赖 PATH、不碰系统软链、不改全局 php，直接指定解释器路径。这是 CI/CD 和多项目共存下的事实标准：
- Linux/macOS：
/usr/bin/php8.2 composer.phar install或php8.2 /path/to/composer.phar update - Windows：
"C:\php\php-8.2.12\php.exe" composer.phar install（路径必须加引号） - Homebrew 用户：
/opt/homebrew/bin/php@8.2 -d memory_limit=-1 /usr/local/bin/composer.phar install（-d参数必须紧接在 PHP 路径后） - 宝塔用户：
/www/server/php/82/bin/php /usr/bin/composer install - 别用
alias composer='php8.2 composer'——在 Git hooks、Makefile、非交互 shell 中大概率失效
COMPOSER_PHP 环境变量是轻量替代方案
Composer 2.2+ 原生支持该变量，比 alias 更可靠，且不影响子进程环境：
立即学习“PHP免费学习笔记（深入）”；
- 临时生效：
COMPOSER_PHP=/usr/bin/php8.1 composer install - 写入 shell 配置：
alias composer81='COMPOSER_PHP=/usr/bin/php8.1 composer' - 注意：如果你的
which composer返回的是 shell 脚本（开头是#!/usr/bin/env php），那COMPOSER_PHP无效——得换成php8.1 /path/to/composer.phar形式
切换后必须删 vendor 和 composer.lock
这不是“建议”，是硬性要求。因为 autoload 文件（如 vendor/composer/autoload_static.php）的生成逻辑与 PHP 版本强相关：
-
match表达式、属性类型声明、联合类型等语法在不同版本下生成的 autoload 结构不同 - 扩展可用性检查（如
ext-mbstring）也发生在 install 阶段，旧版生成的vendor/可能在新版下漏检 - 即使
composer.json里写了"platform": {"php": "8.1.0"}，它只影响依赖解析，不改变已生成的 autoload 文件行为
最容易被忽略的一点：php -v 正确 ≠ composer install 用对了 PHP；config platform.php 设了 ≠ 运行时不报错；删了 vendor 但没删 composer.lock，仍可能复用旧版包缓存导致兼容问题。
