Composer实际使用的PHP版本以composer --version第一行输出为准，或通过head -1 $(which composer)查看shebang；php -v仅反映shell默认PHP，二者可能不一致。
composer --version 第一行显示的 PHP 版本才是真实的
别信 php -v，它只告诉你当前 shell 默认的 PHP，和 Composer 实际用的不是同一个。最准的判断方式只有两个：composer --version 输出第一行（如 PHP 8.2.5 (cli)），或查 shebang：head -1 $(which composer)。如果看到 #!/usr/bin/env php，说明它依赖 $PATH 顺序；如果看到 #!/usr/bin/php8.1，那它就硬绑死了这个路径——升级 Composer 时可能被覆盖，不推荐手动改。
临时换 PHP 版本运行 composer install/update 最可靠
这是 CI/CD、多版本调试、救急验证的首选，绕过所有 alias、PATH、shebang 干扰：
- Linux/macOS：
/usr/bin/php8.1 /usr/local/bin/composer install - macOS Homebrew：
/opt/homebrew/bin/php@8.1 ./composer.phar update（注意@符号不能漏） - Windows：
C:\php-8.2\php.exe C:\tools\composer.phar install - 确保
composer.phar有执行权限：chmod +x composer.phar
这个方式命令一跑完就结束，不污染环境，适合脚本化调用。
config.platform.php 只影响依赖解析，不改变实际运行环境
它不是让 Composer “用 PHP 7.4 运行”，而是告诉依赖求解器：“请当我是在 PHP 7.4.33 下工作”。适用场景是：本地 PHP 是 8.2，但线上是 7.4，你需要生成兼容 7.4 的 vendor/。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 必须写完整版本号，比如
"7.4.33"，不能写"^7.4"或"7.4" - 修改后要执行
composer update --lock重生成composer.lock，否则旧锁文件仍按原平台解析 - 它对扩展检测无效：
ext-pdo是否存在，取决于真实 PHP 加载了哪些.so，不是配置能“假装”出来的
--platform=php:x.x 比 --ignore-platform-req=php 更安全
--ignore-platform-req=php 是跳过校验，容易装出运行时报错的包（比如用了 str_contains() 却部署到 PHP 7.4）；而 --platform=php:8.1（Composer 2.2+ 支持）是临时等效于设置 config.platform.php，既满足约束又保留兼容性检查。
- CI 推荐写法：
composer install --no-interaction --platform=php:7.4.33 - 它不会修改
composer.json，也不影响后续本地开发，纯命令行覆盖 - 注意：该参数只影响本次命令的依赖解析，不改变
composer.lock中记录的 platform 值，除非你加--lock
真正关键的分水岭在于：你是想“控制谁来启动 Composer”，还是“控制 Composer 相信自己在哪个环境里”。这两件事混着做，composer install 就会反复失败。
