Composer不切换PHP版本，只依赖当前shell中php命令指向的解释器；确认实际版本需检查shebang行或直接用目标PHP路径执行composer.phar，config.platform.php仅影响依赖解析而非运行时环境。
Composer 本身不切换 PHP 版本，它只读取当前 php 命令指向的版本做依赖解析；所谓“多版本兼容”，本质是控制「用哪个 PHP 版本去解析依赖」和「让解析结果适配哪个运行环境」——这两件事必须分清，混为一谈就会反复踩坑。
怎么确认当前 Composer 实际用的是哪个 PHP 版本
别信 which php 的路径就代表 Composer 在用它——关键看执行时真正调用的解释器。很多系统里 composer 是 shell 脚本，开头写着 #!/usr/bin/env php，它最终调用的仍是 $PATH 里第一个 php。
- 运行
php -v看终端当前 PHP 版本，这是 Composer 默认依据 - 运行
file $(which composer)，如果输出含 “shell script”，再跑head -n1 $(which composer)查 shebang 行，确认是否硬编码了 PHP 路径 - CI 或脚本中务必加一行
php -v打日志，否则你根本不知道 Composer 底层在用几 - macOS Homebrew 用户特别注意：
php@8.1安装后不会自动替换/usr/bin/php，php -v可能还是系统老版本
怎么让 Composer 按指定 PHP 版本解析依赖（不是“切换系统 PHP”）
最可靠的方式是绕过 composer 命令封装，直接用目标 PHP 解释器执行 composer.phar。这招在本地开发、CI、Docker 里都稳。
- Linux/macOS：
/usr/bin/php8.2 /path/to/composer.phar install（路径必须写全，不能只写php8.2，否则可能被 PATH 干扰） - Windows：
"C:\php\php-8.2\php.exe" composer.phar update（路径含空格必须加双引号） - Mac Homebrew 用户常用：
php@8.2 -d memory_limit=-1 /path/to/composer.phar install（-d参数必须紧跟 PHP 路径后、composer.phar前） - 别用 alias 或 wrapper 脚本替代，它们在非交互式环境（如 Git hooks、Makefile）大概率失效
config.platform.php 是什么，又不是什么
config.platform.php 是 Composer 唯一允许你“覆盖”真实 PHP 版本的地方，但它只影响依赖解析阶段，对运行时零作用——它不是魔法开关，更不是降级适配器。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 适用场景：你在 PHP 8.2 环境里，想提前生成一套适配 PHP 8.0 的
vendor/（比如为部署机准备） - 设置方式：
composer config platform.php "8.0.30"，会写入composer.json的config段 - 必须配合
composer update --lock重生成composer.lock，否则旧锁文件仍记录着高版本包 - 严重误用：本地是 PHP 7.4，设
"platform.php": "8.2"后composer install成功了，但一跑就报ParseError: syntax error, unexpected token "match"——runtime 和 platform 不一致的典型表现
为什么删了 vendor 和 composer.lock 还报错
因为问题不在缓存，而在环境或约束没对齐。删了重装只是用当前 php -v 的版本重跑一遍解析逻辑——如果那个版本本身就不满足 composer.json 里的 "php": "^8.1"，或者你忘了改 config.platform.php，错误会原样重现。
- 先跑
php -v和composer show --platform，确认解析依据和实际平台一致 - 检查
composer.json的require.php是否写了不相交的约束（比如"php": "^7.4"却要求"laravel/framework": "^10.0"） - 用
composer why-not php:8.2快速定位哪个依赖卡住了升级路径 - CI 中每个 job 必须显式指定 PHP 镜像 + 显式调用
phpX.Y composer.phar，不能依赖全局composer命令
真正容易被忽略的点是：autoload 文件本身虽不绑定 PHP 版本，但不同版本下生成的 autoload_static.php 可能因反射行为差异而失效；每次切换 PHP 版本后，必须删掉 vendor/ 和 composer.lock 再重装——复用旧 vendor 是多数“明明版本对了却跑不起来”问题的根源。
