Composer 不解决跨版本兼容问题，它仅按当前 CLI 的 PHP 版本解析依赖；需明确区分“用哪个 PHP 解析”和“匹配哪个运行环境”，否则 install 成功但运行时报 syntax error。
Composer 本身不解决跨版本兼容问题，它只按你当前运行的 PHP 版本做依赖解析；所谓“适配”，本质是控制「用哪个 PHP 版本去解析」和「让解析结果匹配哪个运行环境」——这两件事一旦混淆，composer install 就会成功，php index.php 就直接报 ParseError: syntax error, unexpected token "match"。
怎么确认 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打日志，否则你根本不知道底层在用几
显式调用目标 PHP 二进制是最稳方案
绕过所有封装、alias、PATH 干扰，直接用完整路径启动 composer.phar：
- Linux/macOS：
/usr/bin/php8.2 /path/to/composer.phar install（路径必须写全，不能只写php8.2） - Windows：
"C:\php\php-8.2\php.exe" composer.phar update（路径含空格必须加双引号） - macOS Homebrew 常用：
php@8.2 -d memory_limit=-1 /path/to/composer.phar install（-d参数必须紧跟 PHP 路径后、composer.phar前） - 别用
alias composer='php8.2 composer'：非交互式环境（如 Git hooks、Makefile）大概率失效
config.platform.php 是什么、不是什么
config.platform.php 是 Composer 唯一允许你“声明目标平台 PHP 版本”的配置项，但它只影响 install/update 阶段的依赖解析，对运行时零作用：
立即学习“PHP免费学习笔记（深入）”；
- 适用场景：你在 PHP 7.4 的机器上，但要为 PHP 8.2 的生产环境打包
vendor/（比如 CI 构建部署包） - 设置方式：
composer config platform.php "8.2.0"，会写入composer.json的config段 - 必须配合
composer update --lock重生成composer.lock，否则旧锁文件仍记录着高版本包 - 严重误用：本地是 PHP 7.4，设
"platform.php": "8.2"后composer install成功了，但一跑就报ParseError: syntax error, unexpected token "match"—— 因为platform不会让 PHP 7.4 突然支持 8.2 的语法 - 别把它提交到团队仓库：队友 PHP 版本不一致时，有人
install成功，一跑就崩
每次切换 PHP 版本后必须重装 vendor 和 composer.lock
这不是“清理缓存”，而是因为 vendor/autoload.php 生成逻辑本身受 PHP 版本影响：
- 不同 PHP 版本下，反射行为、扩展可用性、甚至类名大小写处理都可能不同，导致
autoload_static.php或autoload_classmap.php内容不一致 - FPM 和 CLI 版本不一致时，最容易出“安装成功、运行失败”：autoload.php 生成时用了 8.3 的反射行为，但运行时是 8.1，某些类映射或扩展路径就对不上
- 删了再装，只是用当前
php -v的版本重跑一遍解析逻辑；如果php -v还是 7.4，而composer.json里还写着"php": "^8.1"，报错照旧 - CI 脚本中建议固定写法：
rm -rf vendor composer.lock && /usr/bin/php8.2 composer.phar install
最常被忽略的一点：PHP 多版本共存时，composer global require 的安装位置取决于当前 PHP 的 sys_get_temp_dir() 和 get_cfg_var('phar.readonly')，不是 Composer 自身路径——不同 PHP 版本下，~/.composer 可能被不同版本写入，导致命令冲突或 autoload 错乱。
