--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”开头的第五行。