Composer本身不指定PHP路径，只依赖当前shell的php命令；所谓“指定”实为控制调用的php可执行文件，需通过COMPOSER_PHP环境变量（如COMPOSER_PHP=/usr/bin/php8.1 composer install）或显式路径实现，config.platform仅影响依赖解析，不改变实际运行环境。
Composer 本身不指定 PHP 路径，它只用当前 shell 环境的 php 命令；所谓“指定 PHP 路径”，实际是控制它调用哪个 php 可执行文件——这必须靠环境变量或显式命令完成，不是配置项。
COMPOSER_PHP 是唯一可靠的运行时 PHP 路径覆盖方式
当你本地有多个 PHP 版本（比如 PHP 8.1 和 8.3），而希望 composer install 在解析依赖时“假装”运行在 PHP 8.1 下，不能改 composer.json 或写脚本硬编码路径。正确做法是用环境变量 COMPOSER_PHP：
- 它只影响 Composer 自身执行（如 autoload 生成、脚本运行），不影响 vendor 包里 PHP 代码的运行时环境
- 必须在命令前设置：
COMPOSER_PHP=/usr/bin/php8.1 composer install，不能写成export COMPOSER_PHP=...后再单独跑composer install（某些 shell 会丢失继承） - 在 Dockerfile 中推荐写法：
RUN COMPOSER_PHP=/usr/bin/php8.1 composer install --no-dev --optimize-autoloader - 它优先级高于系统默认
php命令，但不会改变php -v输出或扩展加载行为
config.platform 不等于指定 PHP 路径，它只骗过依赖解析
config.platform 是 composer.json 里的字段，常被误认为能“切换 PHP 版本”。它真实作用是：让 Composer 在 update 阶段假装目标环境已满足某些平台要求，从而选到兼容的包版本。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 例如：
"platform": {"php": "8.1.0"}→ Composer 不会装需要 PHP 8.2+ 的包，但它不改你当前php命令指向哪里 - 它对
install阶段无影响（install只读composer.lock），所以生产机上即使php -v显示 8.3，只要 lock 文件里锁的是 8.1 兼容包，就能跑 - 写错格式就失效：版本号必须是完整字符串如
"8.1.0"，不能写"^8.1"或"~8.1" - 真实缺失扩展仍会崩：设了
"ext-gd": "8.1.0"，但系统没装gd扩展，运行时调用imagecreate()还是报Call to undefined function
scripts 里写 php xxx.php 会出问题，因为不走 COMPOSER_PHP
很多人在 composer.json 的 scripts 里写 "test": "php tests/run.php"，以为加了 COMPOSER_PHP 就能控制这个 php 命令——其实不会。Composer 执行 scripts 时，是直接 fork shell 并调用系统 php，完全忽略 COMPOSER_PHP。
立即学习“PHP免费学习笔记（深入）”；
- 正确写法是显式指定解释器：
"test": "/usr/bin/php8.1 tests/run.php"（路径需绝对） - 更可移植的做法：
"test": "php8.1 tests/run.php"，前提是php8.1已在$PATH中且权限正常 - Docker 构建中建议统一用
RUN php8.1 -d memory_limit=-1 vendor/bin/phpunit，避免依赖 Composer 的 script 调度逻辑 - CI 脚本里别省略路径：用
$(which php8.1)动态获取，比硬编码更稳
真正容易被忽略的点是：COMPOSER_PHP 只管 Composer 自己的执行上下文，不管你的应用代码、也不管 scripts 里调用的 php 命令。多 PHP 版本共存时，必须分清「Composer 解析依赖用哪个 PHP」和「你的代码运行在哪个 PHP」——这是两个独立控制面，混用就会出现本地 composer install 成功、但 php index.php 直接报错的情况。
