Composer实际使用的PHP CLI版本需通过composer --version首行或head -n1 $(which composer)查shebang确认，而非php -v；临时指定应直接以目标PHP路径运行composer.phar，如/usr/bin/php8.3 /path/to/composer.phar install。
怎么确认 Composer 实际在用哪个 PHP CLI 版本
别信 which php 或 shell alias，关键看执行时真正加载的解释器。运行 php -v 看终端当前输出，这就是 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 CLI 执行 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（路径含空格必须加双引号）
不要改 composer.bat 或全局 PATH，尤其 Windows 上 composer.bat 第二行常硬编码旧版路径，不改它就永远调错。
立即学习“PHP免费学习笔记（深入）”；
config.platform.php 是什么，什么时候该用、什么时候不该用
config.platform.php 是 Composer 唯一允许你“声明目标平台 PHP 版本”的配置项，它只影响依赖解析阶段（install/update），不改变运行时行为。
适用场景很窄：
- 你在 PHP 7.4 的开发机上，但要为 PHP 8.2 的生产服务器提前生成兼容的
vendor/目录（比如部署包打包） - CI 流水线中明确指定目标环境 PHP 版本，且所有包都已验证过兼容性
禁用场景更关键：
- 本地 PHP 是 7.4，却设
"platform": {"php": "8.2"}后直接跑 Laravel 11 ——match、readonly、命名参数等语法在 7.4 里根本不存在 - 把该配置提交到团队仓库，而队友环境不统一，导致有人
composer install成功但运行时报错
设置方式（仅限当前项目）：composer config platform.php "8.2.0"，之后必须跟 composer update --lock 重写锁文件。
为什么 vendor/autoload.php 在不同 PHP 版本下会出问题
vendor/autoload.php 本身不绑定 PHP 版本，但它加载的类可能依赖特定语言特性。真正冲突点在于：不同 PHP 版本下生成的 autoload_static.php 或 autoload_classmap.php 可能因反射行为差异而失效。
常见表现：
-
composer install成功，但运行时直接报ParseError: syntax error, unexpected token "match" -
Class 'Composer\Autoload\ClassLoader' not found（尤其是create-project拉下来的项目） -
php artisan报错，但换用对应 PHP 版本再执行就正常
本质是：Composer 生成的 autoload 文件结构和内容，会随 PHP 版本（特别是 7.x vs 8.x）的内部 API 差异而变化。一旦用低版本 PHP 生成了本该适配高版本的 autoload，运行时就会挂。
