Composer 会硬性拦截 PHP 版本不匹配：先检查 composer.json 中 "php" 约束是否兼容当前 PHP 版本，不满足则直接终止；可临时用 COMPOSER_PLATFORM_CHECK=0 跳过，或通过 config.platform.php 伪造版本以适配部署环境。
PHP 版本不匹配时 Composer 直接报错
这个错误不是警告，是硬性拦截：Composer 在 install 或 update 前会检查 composer.json 中的 "php" 约束（比如 "^8.1"）是否与当前运行的 PHP 版本兼容。不满足就直接终止，连依赖解析都不做。
常见错误信息长这样：Your Composer dependencies require a PHP version ">=8.1.0"，但你本地跑的是 PHP 7.4 或 8.0 —— 此时别急着升级系统 PHP，先确认你真需要改全局环境。
- 检查当前 PHP 版本：
php -v - 查看项目要求的 PHP 版本：
grep -A5 '"php"' composer.json - 确认 Composer 实际调用的是哪个 PHP：
which php和php -r "echo PHP_BINARY;"
用 COMPOSER_PLATFORM_CHECK=0 临时跳过检查
这是最轻量、最常用的绕过方式，适用于开发调试或 CI 中已确保运行环境一致的场景。它不会修改任何配置，只让 Composer 忽略 "php" 平台约束。
注意：它只跳过 PHP 版本检查，不跳过扩展（如 ext-curl）或其它平台包检查。
立即学习“PHP免费学习笔记（深入）”；
- 临时生效（当前命令）：
COMPOSER_PLATFORM_CHECK=0 composer install - CI/CD 中推荐显式写全：
COMPOSER_PLATFORM_CHECK=0 composer update --no-interaction - Windows cmd 下用：
set COMPOSER_PLATFORM_CHECK=0 && composer install - PowerShell 下用：
$env:COMPOSER_PLATFORM_CHECK="0"; composer install
用 platform 配置伪造 PHP 版本
当你在旧系统上无法升级 PHP，又必须生成可部署的 vendor（比如打包进 Docker 镜像），就得让 Composer “相信”它正在正确的 PHP 上运行。这时靠 config.platform.php 告诉 Composer：“以这个版本为准”，它就会按该版本解析依赖并锁定扩展要求。
这个配置写在 composer.json 的 "config" 下，优先级高于真实环境，且会被 composer.lock 记录，影响所有协作者。
- 添加后运行：
composer update --lock（仅更新 lock 文件，不重装 vendor） - 示例配置：
"config": { "platform": { "php": "8.1.25" } } - 误用风险：如果设成一个项目实际不支持的版本（如设成 8.3 但用了 8.2 才有的函数），运行时会出 fatal error，Composer 不管这个
Docker 或多版本 PHP 环境下怎么选？
本地开发用 phpbrew、asdf 或 Docker 时，关键不是“让 Composer 跑起来”，而是“让 Composer 在对的 PHP 下跑”。很多人卡在路径没切对 —— 比如 phpbrew use 8.1 后忘了重新加载 shell，导致 composer 还调用系统默认 PHP。
- 验证是否生效：
php -v和composer show php（后者显示 Composer 当前识别的 PHP 版本） - Docker 中推荐在
Dockerfile里固定 PHP 版本，并用RUN composer install --no-dev，避免本地环境干扰 - CI 脚本中不要依赖全局
php，显式指定路径更稳，例如：/usr/bin/php8.1 /usr/local/bin/composer install
真正容易被忽略的点是：平台配置和环境变量只影响 Composer 的依赖解析逻辑，不影响运行时。哪怕用 platform 锁定了 PHP 8.1，代码里写了 match 表达式，在 PHP 8.0 环境下照样报错 —— 它不解决执行兼容性问题。
