Composer本身不管理PHP版本，真正需控制的是启动composer.phar的PHP解释器；最稳方式是用完整路径显式调用，如/usr/bin/php8.2 /usr/local/bin/composer install，并删vendor与composer.lock后重装。
Composer 本身不管理 PHP 版本，也没有内置的“多版本切换工具”。你真正需要的不是 Composer 的功能，而是控制「哪个 PHP 解释器启动了 composer.phar」——所有所谓“多版本共存”，本质都是路径调度问题。
怎么让 composer install 用指定 PHP 版本运行
最稳、无需配置、不污染环境的方式：把 PHP 可执行文件的完整路径写在 composer.phar 前面。
-
/usr/bin/php8.2 /usr/local/bin/composer install（Ubuntu/Debian） -
/opt/homebrew/bin/php@8.3 /usr/local/bin/composer update（macOS Homebrew） -
C:\php\php-8.1.25\php.exe C:\myproject\composer.phar require guzzlehttp/guzzle（Windows） - 别依赖
which composer输出的路径——如果它是 shell 脚本（比如宝塔或某些安装包自带的），里面可能硬编码了#!/usr/bin/env php，实际调用的还是 PATH 里第一个php - 验证是否生效：运行
php -v和/path/to/php -v对比；再跑/path/to/php /path/to/composer.phar --version看输出是否一致
为什么 config.platform.php 不等于“切换 PHP 版本”
config.platform.php 是个常见误解点。它只影响 Composer 解析依赖时的“判断逻辑”，不改变任何运行行为。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 写
"config": {"platform": {"php": "8.1.10"}}后，必须立刻运行composer update --lock，否则composer.lock仍按旧平台生成 -
composer show php输出的是这个 platform 值，不是php -v结果——别拿它当真实环境验证依据 - 它不能让你在 PHP 7.4 上跑
match表达式：语法错误是 PHP 解析器报的，platform不参与运行时编译 - 团队协作中，若有人本地没配对
php -v和platform，composer install成功但一运行就ParseError
全局 composer 命令为什么不可靠
大多数系统里所谓的 composer 命令，其实是个 shell 脚本或 bat 包装器，内部绑定了某个固定 PHP 路径。
- 运行
file $(which composer)，如果输出含 “shell script”，说明它不是直接的 PHP 脚本 - 运行
head -n1 $(which composer)，看 shebang 行是不是#!/usr/bin/env php或硬编码路径（如#!/usr/bin/php7.4） - alias
composer='php8.2 composer.phar'在 CI、Makefile、Git hooks 中基本失效，因为子 shell 不继承 alias - 更安全的做法是废弃全局
composer，在项目根目录放一个Makefile或.env.example，明确写：install: php8.2 composer.phar install
真正的复杂点不在 Composer 配置，而在于你能否清晰区分「PHP CLI 运行时版本」「Composer 解析依赖时假装的平台版本」「Web 服务器使用的 PHP 版本」——这三者完全独立，混用就会导致本地能装、线上跑崩、CI 报错却查不出原因。
