--prefer-lowest让Composer安装各依赖在约束范围内的最低稳定版本，用于验证兼容性边界；仅对composer update生效，需配合--dry-run、--no-dev等参数在CI中安全使用。
什么是 --prefer-lowest，它到底装什么
--prefer-lowest 告诉 Composer 尽可能安装每个依赖的**最低允许版本**（即 composer.json 中约束范围内的最小稳定版），而不是默认的最新兼容版。它不强制降级已锁定的 composer.lock 版本，但会在无 lock 文件或执行 composer update --prefer-lowest 时生效。
典型用途是验证你的包是否真能兼容所有声明支持的旧版本依赖——比如你写了个 Laravel 包，声明支持 "laravel/framework": "^8.0 || ^9.0 || ^10.0"，用 --prefer-lowest 就会尝试装 8.0.0（而非 8.99.9）来测边界兼容性。
实际怎么跑：update 还是 install？
必须用 composer update，composer install 忽略 --prefer-lowest 参数（它只按 composer.lock 安装，不重新解析约束）。
- 首次测试：删掉
composer.lock，再运行composer update --prefer-lowest --no-interaction
- 已有项目想重测：先
git clean -fdx清掉vendor/和composer.lock，再执行上面命令 - 只想测某几个包：加包名，如
composer update --prefer-lowest --no-interaction guzzlehttp/guzzle symfony/http-foundation
常见失败原因和绕过技巧
失败往往不是你代码有问题，而是某些低版本依赖本身存在已知 bug 或 PHP 版本不兼容。
-
phpunit/phpunit9.5.x 要求 PHP >=7.3，但你本地是 PHP 8.2？没问题；反过来，若你锁了"php": "^7.4"却在 PHP 8.2 下跑--prefer-lowest，Composer 可能挑出一个根本不支持 PHP 8.2 的旧扩展（比如ext-mcrypt已废弃），直接报错退出 - 某些包的最低版根本没发布
composer.json中要求的 autoloading 配置，导致vendor/autoload.php加载失败 —— 这类得手动查该包的最低 tag，看其composer.json内容是否合规 - 想跳过 dev 依赖？加
--no-dev，否则--prefer-lowest也会拉最低版的phpunit、mockery，而它们的最低版可能早就不支持你当前的 PHP
CI 中如何安全使用 --prefer-lowest
GitHub Actions / GitLab CI 里别直接 composer update --prefer-lowest 后跑全量测试——很可能因某个低版本依赖的 bug 导致测试假失败。
- 推荐拆成两步：先
composer update --prefer-lowest --dry-run
检查是否能解析成功（返回 0 表示约束无冲突） - 再真正更新并限制 PHP 版本，例如在 PHP 7.4 环境下跑：
composer update --prefer-lowest --no-interaction --no-dev
- 如果项目用
composer.lock提交到仓库，记得测试完不要提交生成的 lock 文件——它只是临时兼容性快照
最易被忽略的一点：很多项目把 --prefer-lowest 当成“一键兼容测试”，但其实它只解决“能不能装”，不保证“装完能跑”。函数签名变更、行为差异、弃用警告升级为错误（如 PHP 8.1 的 strlen(null)），这些都得靠真实测试覆盖。
