Composer 本身没有 --php-version 这类参数，记住，它用的是哪个 PHP 版本，完全取决于你执行命令时，Shell 调用的是哪个 php 可执行文件。这事儿有点像问“司机开的是哪辆车？”——答案不取决于导航软件，而取决于你上了哪辆车。所以，当你看到报错 Your PHP version X.Y.Z does not satisfy that requirement 时，先别急着怀疑人生，大概率是“上车”这个环节出了偏差。
怎么确认当前 composer 用的是哪个 PHP？
很多人习惯用 php -v 来确认，但这里要提醒一句：php -v 显示的只是系统默认的 PHP，并不等于 composer 正在用的那个。最准的方法是直接看源头：
- 运行
composer --version，第一行会直接告诉你它绑定的 PHP 版本，比如PHP 8.2.5 (cli) (built: ...)，这个信息是实打实的。 - 或者查一下 shebang：
head -1 $(which composer)，看看文件头是不是硬编码了某个具体路径，比如#!/usr/bin/php7.4。如果是#!/usr/bin/env php，那就说明它走的是系统默认的php，这时候$PATH里谁排在前面，谁就是它。 - 如果输出里压根没带 PHP 版本信息，那基本可以确定 composer 是通过系统
php命令调起的，这时候就得看$PATH的优先级了。
临时指定 PHP 路径运行 composer install/update
这是最直接、最可控的方式，没有之一。尤其适合 CI/CD 流水线，或者本地同时装了多个 PHP 版本的情况：
- 直接用完整路径调用目标 PHP：比如
/usr/bin/php8.1 /usr/local/bin/composer install。这就像你直接告诉司机“开这辆车”，而不是让系统帮你选。 - 如果你用的是
composer.phar，别忘了给它可执行权限：chmod +x composer.phar，然后运行/usr/bin/php8.1 ./composer.phar update。 - macOS 的 Homebrew 用户要注意：
brew link php@8.1只改了$PATH，但不会影响已经存在的全局composer命令。它可能还在绑定旧版 PHP，所以别被brew link的结果迷惑了。 - Windows 用户直接用绝对路径：
C:\php-8.2\php.exe C:\tools\composer.phar install，省心省力。
用 config.platform.php “假装”运行在某个 PHP 版本
这个配置并不改变实际运行的 PHP 版本，它只影响依赖解析的逻辑——说白了，就是让 Composer 在解析依赖时，以为你正在用某个特定版本的 PHP。这个功能最适合的场景是：你本地 PHP 是 8.2，但线上环境是 8.1，你需要在本地构建一个兼容 8.1 的包。
操作方式如下：
- 在
composer.json里写入："config": { "platform": { "php": "8.1.10" }}注意，这里必须写完整的版本号，比如"8.1.10"，写成"8.1"或"^8.1"都是无效的。 - 改完之后，别忘了执行
composer update --lock，否则composer.lock还是会按旧平台生成。 - 验证是否生效：可以用
composer show -p查看platform.php的值，或者直接用composer show php。 - 这个配置只管
"php"字段和扩展的存在性（比如ext-mbstring），但不管函数是否存在。比如str_contains()在 PHP 8.0+ 才有，如果你把平台设为"8.0.0"，它不会阻止你安装包含这个函数的包。这一点需要特别留意。
为什么不能只靠 --ignore-platform-req=php？
有些朋友遇到版本不匹配的问题，第一反应就是加个 --ignore-platform-req=php 参数跳过校验。这个做法确实能绕过报错，但风险不小：
composer install --ignore-platform-req=php会让 Composer 忽略所有"php": "..."的约束。这意味着，如果你的项目要求php: ^8.0，但你在 PHP 7.4 环境下强装，vendor 目录里就可能出现match表达式之类的语法糖，上线直接 fatal error。- 这个参数也不解决扩展缺失的问题。即使你跳过了 PHP 版本检查，如果
ext-gd没装，composer install依然会失败。 - 在 CI 流水线里用这个参数，等于把兼容性问题延迟到运行时才暴露，到时候排查成本比现在高得多。
说到底，composer.json 里的 "php" 字段约束的是“依赖包能否被安装”，而你执行 composer install 时用的 PHP 版本，决定了“这些包能不能被正确解析和加载”。这两者必须对齐，否则 vendor 目录里就会埋下隐患。最稳妥的做法，永远是先确定目标运行环境的 PHP 版本，再用那个版本去跑 install 或 update，而不是事后补救。
