--prefer-lowest 仅在 composer update 中生效，composer install 完全忽略该标志；需配合 config.platform 锁定环境并清除 vendor 和 composer.lock 后执行 composer update --prefer-lowest --no-interaction 才能可靠触发最低兼容依赖解析。
为什么 --prefer-lowest 不能只靠 composer install 触发
它只在 composer update 时生效，composer install 完全忽略这个 flag —— 即使 composer.lock 不存在或已删掉。很多人跑完 composer install --prefer-lowest 发现版本没变，就是因为命令压根没起作用。
真正触发最低依赖的路径是：先确保 composer.json 中所有依赖写的是版本范围（如 "monolog/monolog": "^2.0"），再运行：
composer update --prefer-lowest --no-interaction
其中 --no-interaction 很关键，否则遇到提示（比如要不要删除未声明包）会卡住 CI 流程。
--prefer-lowest 实际选的是“满足约束的最低可安装版本”，不是“历史最早版”
它不会选一个早已 EOL、PHP 不兼容、甚至 require 冲突的版本。Composer 会从当前平台环境（PHP 版本、已启用扩展等）出发，反向推导出每个包能装的最低合法版本。
- 例如
"phpunit/phpunit": "^9.0"在 PHP 8.2 下，--prefer-lowest可能选9.5.0，而不是9.0.0（后者不支持 PHP 8.2） - 如果某个子依赖（如
sebastian/exporter）在9.0.0中要求php: >=7.3，但你的 PHP 是 8.0，那 Composer 会跳过它，继续找下一个满足条件的最低版 - 所以结果不可预测，每次
composer update --prefer-lowest都可能不同，尤其当上游包频繁调整composer.json的require
CI 中做最低版本测试，必须锁定平台配置
本地 PHP 8.1 跑出来的 --prefer-lowest 结果，放到 GitHub Actions 的 PHP 8.3 环境里很可能失败——不是你代码问题，是依赖解析路径变了。
解决方案是显式声明目标平台，用 config.platform 模拟旧环境：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer config platform.php 7.4.0
然后再执行 update。这样即使你在 PHP 8.2 上操作，Composer 也会假装自己在 7.4 下解依赖，从而拉到更老的、兼容 7.4 的最低组合。
常见遗漏点：
- 忘了清掉
vendor/和composer.lock，导致旧 lock 文件残留影响结果 - 没设
platform.ext-*（如platform.ext-redis），而某依赖最低版偏偏需要 redis 扩展，CI 就会因扩展缺失报错 - 用了
require-dev里的工具链（如phpstan/phpstan），它们的最低版可能不支持当前 PHP，直接让 update 失败
怎么验证 --prefer-lowest 真生效了
别只信终端输出，直接看生成的 composer.lock 文件最可靠。重点关注两个字段：
-
"packages"数组里每个包的"version"值，对比正常composer update后的 lock，明显更旧才算成功 -
"content-hash"一定和常规 update 不同，相同就说明根本没走最低逻辑
一个小技巧：加 -v 参数看详细日志，搜索 Resolving dependencies 行，后面紧跟着的包名和版本就是 Composer 实际挑中的最低候选 —— 这里能看到它跳过了哪些“理论上更低但不兼容”的版本。
真正麻烦的不是命令怎么敲，而是你得接受：同一个 composer.json，在不同 PHP 版本、不同平台配置、不同时间点跑 --prefer-lowest，得到的依赖树大概率不一样。它是个动态求解过程，不是快照回放。
