Composer实际使用的PHP版本取决于执行时调用的php可执行文件；可通过composer --version首行或head -1 $(which composer)查看shebang确认；临时指定路径（如/usr/bin/php8.1 composer install）最可靠；config.platform.php仅影响依赖解析，不改变实际运行环境。
Composer 本身不选 PHP 版本，是你调用它时用的 php 可执行文件决定了版本。所有“设置”动作，本质都是控制这个调用链——不是配置 Composer，而是指定谁来启动它。
怎么确认 composer 实际在用哪个 PHP？
别看 php -v，它只告诉你当前 shell 默认的 php，和 composer 无关。真正靠谱的方式只有两个：
- 运行
composer --version，第一行会明确写出类似PHP 8.2.5 (cli)的信息——这就是它正在用的版本 - 运行
head -1 $(which composer)，看 shebang 行：#!/usr/bin/env php表示它依赖$PATH查找；#!/usr/bin/php8.1表示硬编码了路径，改不了
如果两者不一致（比如 composer --version 显示 8.1，但 php -v 是 8.2），说明你在某个非标准环境里执行（如 sudo、CI 脚本、IDE 终端），$PATH 没继承过来。
临时指定 PHP 版本运行 composer install/update
这是最干净、最可靠、CI/CD 必须用的方式。绕过所有 alias、PATH、shebang 干扰，直接拼出完整命令：
立即学习“PHP免费学习笔记（深入）”；
- Linux/macOS：
/usr/bin/php8.1 /usr/local/bin/composer install或/opt/homebrew/bin/php@8.3 ./composer.phar update - Windows：
C:\php-8.2\php.exe C:\tools\composer.phar install - 确保
composer.phar有执行权限（chmod +x composer.phar） - 别用
alias composer='php8.1 composer'—— 在 Makefile、Git hooks、CI 脚本里完全不生效
这个方式不改系统配置，不污染全局，适合多项目混用不同 PHP 版本的场景。
config.platform.php 是什么，什么时候该用？
它不是让 Composer “换 PHP”，而是让它“假装”自己运行在某个 PHP 版本下，只影响依赖解析逻辑：
- 适用场景：你在 PHP 8.2 环境开发，但线上是 PHP 8.1，想确保装出来的包兼容 8.1（比如避免装到依赖
ext-gmp的新版ramsey/uuid） - 写法必须是完整版本号：
"config": {"platform": {"php": "8.1.10"}}，不能写"^8.1"或"8.1" - 改完要跑
composer update --lock，否则composer.lock还是按旧平台生成的 - 验证是否生效：
composer show php输出的版本就是platform.php值，不是php -v
它不解决运行时报错（比如 Class not found），那些问题只靠真实 PHP 环境一致性才能避免。
require.php 和 platform.php 的区别必须分清
这两个字段干的事完全不同，混用会导致本地能跑、上线就崩：
-
"require": {"php": ">=8.1.0"}是闸门：当前运行 composer 的 PHP 版本低于 8.1.0，install直接中断报错 -
"config": {"platform": {"php": "8.1.10"}}是过滤器：告诉 Composer “请按 PHP 8.1.10 的能力去挑包”，哪怕你实际用的是 8.2 - 漏掉
require.php，部署到低版本服务器时 runtime 错误才暴露；漏掉config.platform.php，本地装的包可能因扩展缺失或语法差异在目标环境崩溃
真正关键的不是写哪条配置，而是每次执行 composer install 时，php 命令指向的可执行文件，必须和你要交付的运行环境一致——这点最容易被忽略，也最难排查。
