--prefer-lowest 是让 composer 在满足所有约束前提下选各包最早可用版本，用于暴露隐式依赖高版本特性的脆弱点，而非单纯降级；它常因依赖冲突失败，需结合报错日志中的“because”链定位根本原因。
用 --prefer-lowest 不是为了“测最低版本”，而是为了暴露你代码里那些没声明却偷偷依赖高版本特性的脆弱点。
为什么 --prefer-lowest 经常装不成功
它不是“降级安装”，而是让 Composer 在满足所有 require 约束的前提下，**尽可能选每个包的最早可用版本**。一旦某个依赖的最低版本无法满足其子依赖的最低要求，整个安装就失败——这不是 bug，是提示你约束写得太松或太紧。
- 常见错误现象：
Your requirements could not be resolved to an installable set of packages. - 典型场景：项目
composer.json里写了"monolog/monolog": "^2.0"，但monolog 2.0.0本身要求php >=7.2，而你本地是 PHP 7.1 → 直接失败 - 参数差异：
--prefer-lowest必须和install或update一起用，单独运行无效；它不会改写composer.lock，除非你加-W（--write-lock） - 性能影响：解析版本树比默认策略更耗时，尤其依赖多、约束杂的项目，别在 CI 里无条件加
--prefer-lowest 的正确触发时机
它只在你明确想验证“向下兼容性”时才有意义，比如发版前、升级 PHP 版本前、或维护一个要支持老环境的 SDK。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 不要在日常开发中加，会拖慢
composer install - CI 中建议只在专用 job 里跑：
composer update --prefer-lowest --no-interaction - 如果失败，先看报错里卡在哪一个包，再检查它的
composer.json原始约束（比如是否意外拉了 dev-main 或带@dev的版本） - 必要时配合
--ignore-platform-reqs（慎用），绕过 PHP 扩展或版本限制，但得清楚后果
和 --prefer-stable 混用时的陷阱
两者逻辑不同：--prefer-stable 是优先选 stable 标签版本；--prefer-lowest 是优先选数字最小的满足约束的版本——它们可能冲突。
- 常见错误现象：加了
--prefer-lowest却装出dev-master→ 因为某个包的最低稳定版根本不在当前约束范围内，Composer 只能退到 unstable 版来解依赖 - 解决办法：显式锁定关键包的最低稳定版，例如：
"symfony/console": "5.4.*"而不是"^5.4"，避免它去抓5.4.0-beta1 - 兼容性影响：某些包的最低版根本不提供 autoloading 配置，或用了已废弃的函数，
--prefer-lowest会立刻暴露这类问题
真正难的不是加参数，而是看懂失败日志里那一长串“because”链条——哪一行约束松了，哪个包悄悄升了主版本，哪条 conflict 规则被忽略了。这些细节藏在输出最底下，很多人扫一眼报错就去删 vendor 重试，其实该盯的是那个“because”开头的第五行。
