Composer报PHP版本不满足约束，本质是其实际调用的PHP解释器与终端php -v显示版本不一致，常见于alias、wrapper或PATH劫持；需用which composer、head -n1检查脚本头，并通过COMPOSER_PHP=/path/to/php8.2 composer install确保版本统一。
composer install 报 PHP 版本不满足，但 php -v 显示正确
这不是 Composer 的 bug，而是它实际调用的 PHP 解释器和你终端里看到的不是同一个。Composer 是个 PHP 脚本，启动时依赖 php 命令——但这个命令可能被 alias、wrapper 或 PATH 顺序劫持。
常见现象：
-
php -v输出 8.2，composer --version也显示正常，但composer install却报requires php ^8.2 but your php version (7.4.33) does not satisfy that requirement - 执行
which composer返回的是 shell alias 或 wrapper（如宝塔、Homebrew 的封装脚本），里面硬编码了旧版 PHP 路径 - 在 CI/CD 或 Docker 中，
php和composer是分别安装的，版本不一致
验证方法：
- 运行
head -n1 $(which composer)，看第一行是不是#!/usr/bin/env php或具体路径（如#!/usr/bin/php8.1） - 紧接着连续执行两次
php -v：一次在composer --version前，一次在之后。如果输出不同，说明 composer 被某层 wrapper 接管了
COMPOSER_PHP 环境变量为什么有时不生效
COMPOSER_PHP 是 Composer 官方支持的运行时 PHP 路径覆盖方式，但它只影响 Composer 自身执行逻辑（比如 autoload 生成、scripts 中的 php 命令），不改变 php -v 输出，也不控制 scripts 里显式写的 php xxx.php。
立即学习“PHP免费学习笔记（深入）”；
失效场景：
- 写成
export COMPOSER_PHP=/usr/bin/php8.2后再单独跑composer install—— 某些 shell（尤其是非交互式环境如 CI）不会继承该变量 - 在
composer.json的scripts里写"test": "php tests/run.php"—— 这里的php不走COMPOSER_PHP，必须写成"test": "/usr/bin/php8.2 tests/run.php" - 用了
sudo composer install——sudo默认不传环境变量，COMPOSER_PHP丢失
可靠写法：
-
COMPOSER_PHP=/usr/bin/php8.2 composer install（命令前直接赋值） - Dockerfile 中：
RUN COMPOSER_PHP=/usr/bin/php8.2 composer install --no-dev
config.platform.php 和顶层 "php" 约束谁说了算
"config": {"platform": {"php": "8.2.0"}} 只骗过依赖解析阶段，它让 Composer 在 update 时“假装”运行在 PHP 8.2 下；而 "require": {"php": "^8.2"} 是真实要求，冲突时后者起决定作用。
关键区别：
-
config.platform.php对install阶段无影响 —— 它只参与 SAT 求解，不改实际执行环境 - 版本号必须是完整字符串，如
"8.2.0"，不能写"^8.2"或"~8.2"，否则配置无效 - 设了
"ext-gd": "8.2.0"但系统没装 gd 扩展？运行时仍会崩，config.platform不解决真实扩展缺失问题 - CI 构建时想复现生产环境？别只靠
platform，必须保证composer install实际运行在目标 PHP CLI 版本下
切换 PHP 版本后 vendor/autoload.php 为什么报错
不是路径错了，是 autoload 文件本身在不同 PHP 版本下生成逻辑不同。PHP 8.2 的 match 表达式、联合类型反射、opcache.enable_cli 开关状态，都会影响 vendor/composer/autoload_static.php 的内容。
后果：
- PHP 8.3 生成的 autoload 文件，在 PHP 8.1 下运行到含
never类型声明的类时直接ParseError - 即使
autoload.php能加载，类定义顺序或魔术方法注册差异也可能导致Class not found -
composer.lock里锁的是包版本，但不锁生成环境 —— 同一 lock 文件，在不同 PHP 版本下composer install产出的 autoload 文件不兼容
所以每次切换 CLI PHP 版本后，必须：
- 删掉
vendor/和composer.lock - 用目标 PHP 版本重新执行
/usr/bin/php8.2 composer install - 不要试图复用旧 vendor —— 它不是“缓存”，而是与生成环境强绑定的产物
