Composer本身不管理PHP版本，只依赖当前shell中php -v输出的版本解析依赖；需显式调用目标PHP二进制（如/usr/bin/php8.3 composer.phar install）并删除vendor与composer.lock后重装，config.platform.php仅影响依赖解析，不改变运行时环境。
Composer 本身不管理 PHP 版本，它只认你当前 shell 里 php -v 输出的那个版本。所谓“多版本共存下的依赖管理”，本质是控制「用哪个 PHP 解释器执行 composer install」，以及「让生成的 vendor/ 适配哪个运行环境」——这两件事必须对齐，否则安装成功、运行报错是常态。
怎么确认 Composer 实际在用哪个 PHP 版本
别信 which php 或 alias，关键看执行时真正加载的解释器：
- 运行
php -v看终端当前 CLI 版本，这是 Composer 默认依据 - 运行
file $(which composer)，如果输出含 “shell script”，再跑head -n1 $(which composer)查 shebang 行——很多系统里它是#!/usr/bin/env php，最终仍走$PATH里第一个php - macOS Homebrew 用户特别注意：
php@8.2安装后不会自动替换/usr/bin/php，php -v可能还是系统老版本 - CI 或脚本中务必加一行
php -v打日志，否则你根本不知道 Composer 底层在用几
如何让 Composer 显式用指定 PHP 版本执行 install/update
最稳、最透明、最不容易出错的方式：绕过所有封装、alias、PATH 干扰，直接调用目标 PHP 二进制执行 composer.phar：
- Linux/macOS：
/usr/bin/php8.3 /path/to/composer.phar install（路径必须写全，不能只写php8.3） - macOS（Homebrew）：
php@8.3 -d memory_limit=-1 /path/to/composer.phar install（-d参数必须紧跟 PHP 路径后、composer.phar前） - Windows：
"C:\php\php-8.3.12\php.exe" composer.phar install（路径含空格必须加双引号）
别用 alias composer='php8.3 composer'：非交互式环境（如 Git hooks、Makefile）大概率失效。
立即学习“PHP免费学习笔记（深入）”；
config.platform.php 是什么、什么时候该用
config.platform.php 是 Composer 唯一允许你“声明目标平台 PHP 版本”的配置项，但它只在 install/update 阶段起作用，对运行时零影响：
- 适用场景很窄：你在 PHP 7.4 的机器上，但要为 PHP 8.2 的生产环境打包
vendor/（比如 CI 构建部署包） - 设置方式：
composer config platform.php "8.2.0"，之后必须跟composer update --lock重写锁文件 - 严重误用：本地是 PHP 7.4，设
"platform": {"php": "8.2"}后直接跑 Laravel 11 ——match、readonly、命名参数等语法在 7.4 里根本不存在 - 该配置不会被子项目继承，每个项目需单独设置
为什么每次切换 PHP CLI 版本后必须删 vendor 和 composer.lock
因为 Composer 生成的自动加载文件（如 vendor/composer/autoload_static.php）会根据当前 PHP 版本的反射行为、类加载顺序和语法支持做静态优化：
- PHP 8.2 的
match表达式在 8.1 下无法解析，即使autoload.php文件本身没报错，一执行到具体类就会ParseError - PHP 7.4 生成的
autoload_static.php不含联合类型检查逻辑 - 扩展加载顺序差异（如
opcache.enable_cli开关状态）会影响类定义缓存
所以每次切换 PHP CLI 版本后，必须执行：rm -rf vendor composer.lock，再用对应版本的 PHP 二进制重新 composer install。漏掉这步，就是把问题延后到运行时爆发。
