composer install 用的是终端中 php 命令指向的 CLI 版本，而非 Web 服务器（如 Nginx+PHP-FPM）所用版本；该版本决定依赖解析、autoload 文件生成及锁文件内容，切换 PHP 版本后必须删除 vendor 和 composer.lock 并重新 install，否则因反射行为、语法支持和扩展路径差异导致运行时错误。
composer install 用的是哪个 PHP 版本？
它用的是你终端里 php 命令指向的那个二进制，不是 Nginx 或 Apache 背后跑的 PHP-FPM。比如 phpinfo() 显示 Web 环境是 PHP 8.3，但 php -v 输出 8.1，那 composer install 就按 8.1 解析依赖、生成 vendor/autoload.php —— 即使你目标环境是 8.3，结果也可能是错的。
为什么 vendor/autoload.php 在不同 PHP 版本间不能复用？
Composer 生成的自动加载文件（如 vendor/composer/autoload_static.php）会根据当前 PHP 版本的反射行为、类加载顺序和语法支持做静态优化。例如：
- PHP 8.2 生成的 autoload 文件可能内联了
match表达式，PHP 8.0 运行时直接报ParseError: unexpected token "match" - PHP 8.1 的只读属性（
readonly）在 8.0 下无法解析，autoload 初始化就失败 - 扩展路径、函数签名、类型推导差异也会导致
class_exists()或is_callable()返回不同结果
platform.php 配置只骗过安装，不骗过运行
"config": {"platform": {"php": "8.3.0"}} 是编译期“伪装”，仅影响 composer install 阶段的依赖选择和锁文件生成，不改变实际执行环境。常见误用场景：
- 本地 PHP 是 8.1，设
"platform": {"php": "8.3.0"}后装了 Laravel 11 —— 运行时报错Fatal error: Uncaught Error: Undefined constant "true"（因 8.1 不支持 8.3 的布尔字面量优化） - CI 中用了 platform 配置但没验证 runtime 是否真有对应版本，部署后 500 错误才暴露
- 提交了该配置到团队仓库，队友没同步 PHP 版本，
composer install成功但php artisan serve直接崩溃
切换 PHP 版本后必须重装 vendor
哪怕只是从 8.2 切到 8.3，也得删掉 vendor 和 composer.lock 再 composer install。原因很实在：
立即学习“PHP免费学习笔记（深入）”；
-
composer.lock记录的是上一次解析时选中的包版本，而不同 PHP 版本下可选版本范围不同（比如某包 v2.0 支持 8.2+，v1.9 支持 8.0+） -
vendor/autoload.php是基于旧版本 PHP 生成的，结构和内容已固化，不会随 CLI 版本切换自动更新 - 不清理就复用，等于把为 PHP 8.2 编译的代码扔进 PHP 8.3 运行时，反射行为、opcache 优化路径都可能错位
最易被忽略的一点：IDE（如 PHPStorm）或终端 shell 可能缓存了旧的 php 路径，which php 和 php -v 看似一致，但实际执行 composer install 时调用的仍是旧二进制 —— 建议每次操作前先 /usr/bin/php8.3 -v 显式验证。
