Composer install卡在PHP版本不满足要求，是因为它在解析依赖前就严格校验composer.json中"php"字段（如"^8.1"）与当前CLI的php -v版本（如7.4.33）是否匹配，不匹配则直接拒绝，不降级选包、不报具体冲突包。
为什么composer install会卡在“PHP版本不满足要求”
不是 Composer 本身坏了，也不是网络或权限问题，而是它在解析依赖树前就直接拒绝了——因为 composer.json 里某个包（甚至是你自己写的）声明了 "php": "^8.1"，而你终端里运行 php -v 输出的是 7.4.33。Composer 不会尝试降级选包，它只找「完全匹配」的组合；一旦发现平台环境不达标，连具体哪个包冲突都不报，直接抛出 Your PHP version (7.4.33) does not satisfy that requirement。
用--ignore-platform-reqs能绕过，但别当真
这个参数本质是让 Composer 忽略所有平台约束：PHP 版本、扩展（如 ext-gd）、甚至 ICU 版本。你可以临时跑通流程：
composer install --ignore-platform-reqs
但它不会让代码真正跑起来。如果包里用了 match 表达式（PHP 8.0+）或只读属性（PHP 8.2+），你的 PHP 7.4 会在第一次调用时直接 Fatal error。更危险的是，它还会跳过扩展检查——比如缺 ext-openssl，composer install 成功了，但后续 file_get_contents('https://...') 就会静默失败。
- 仅限本地快速验证逻辑，且你确认没用高版本语法
- 绝对不要提交生成的
composer.lock到团队仓库 - CI/CD 或生产环境禁用——它掩盖问题，不解决问题
--ignore-platform-req=php 比 --ignore-platform-reqs 更精准
如果你只是想跳过 PHP 版本校验，但保留对扩展、ICU 等其他平台项的检查，应该用带参数的写法：
立即学习“PHP免费学习笔记（深入）”；
composer update --ignore-platform-req=php
这样至少还能捕获 ext-mbstring 缺失这类真实运行时风险。对比之下，--ignore-platform-reqs 是“全关”，而 --ignore-platform-req=php 是“只关 PHP 这一扇门”。
- 支持多次指定：
--ignore-platform-req=php --ignore-platform-req=ext-gd - 不会影响
config.platform.php的设置，两者可共存（但语义容易混淆，慎用） - 执行后仍需手动验证：用
php -l vendor/some/package/src/Class.php扫描关键文件，看是否有语法级不兼容
真正该盯住的其实是 php -v 和 which php
很多人改完 PHP 版本，php -v 显示对了，但 composer install 依然报旧版本错误——因为 Composer 调用的是 shell 中的 php 命令，而这个命令可能被 alias、shell 函数或 PATH 顺序干扰。最稳的方式是显式调用：
/usr/local/bin/php8.2 /usr/local/bin/composer install
或者在 macOS 上用 Homebrew 切换后，立刻验证：
which php<br>php -v<br>composer diagnose | grep "PHP binary"
注意：Web SAPI（如 Apache mod_php）的版本和 CLI 完全无关，Composer 只认 CLI。
最容易被忽略的一点：config.platform.php 是“假装有”，require.php 是“真要”，而 php -v 是“实际有”。三者不一致时，错误永远发生在最弱的那个环节上——通常是那个你没去 which 的 php。
