--prefer-lowest 是 CI 中依赖兼容性测试的关键开关，它强制 Composer 安装满足版本约束的最低依赖版本，模拟旧版生态集成场景，并需配合 phpunit 等测试命令才能有效验证兼容性。
为什么 --prefer-lowest 是 CI 中依赖兼容性测试的关键开关
它强制 Composer 安装每个依赖能解析到的最低版本（满足 composer.json 中版本约束的下限），而不是默认的最新兼容版。这直接模拟了“你的包被旧版生态集成”的真实场景——比如用户还卡在 symfony/console v5.4，或仍在用 phpunit 9.5。
--prefer-lowest 在测试流程中怎么用才有效
它本身不运行测试，只控制依赖安装行为；必须配合实际测试命令（如 phpunit）才能验证兼容性。常见误用是只跑 composer install --prefer-lowest 就认为测试完成，结果没执行任何断言。
- CI 中典型组合：
composer install --prefer-lowest && vendor/bin/phpunit
- 需确保
composer.json的require和require-dev约束合理——例如写成"phpunit/phpunit": "^9.0"才可能降到 9.0.0；若写成"^9.5"，最低就只能是 9.5.0 - 搭配
--no-interaction和--no-progress避免 CI 卡住或输出干扰日志
容易被忽略的陷阱：它不解决语义冲突，只暴露问题
--prefer-lowest 不会修复代码里对高版本 API 的硬依赖。它只是让问题提前浮现——比如你用了 Stringable::toString()（PHP 8.0+），但 --prefer-lowest 拉来 PHP 7.4 + 旧版 symfony/polyfill，测试当场失败。
- 它无法绕过 PHP 版本限制：如果
composer.json声明"php": "^8.1"，那--prefer-lowest也不会降 PHP 版本，只会降其他包 - 某些包的最低版本可能已废弃（如
guzzlehttp/guzzlev6.5.x 已 EOL），CI 报错不是你的错，而是提醒你该收紧require范围 - 与
--prefer-stable同时使用时，优先级是：先满足 stable，再取 lowest —— 若最低可用版是 dev 分支，它会被跳过
和 --prefer-dist、--with-all-dependencies 的关系
完全无关。这三个参数作用域不同：--prefer-dist 控制下载源（zip vs git clone），--with-all-dependencies 影响依赖树展开深度，而 --prefer-lowest 只改版本选择策略。混用没问题，但别指望它们协同解决兼容性问题。
真正要小心的是锁文件残留——本地 composer.lock 若存在，--prefer-lowest 可能被忽略。CI 中务必加 rm composer.lock 或用 --ignore-platform-reqs（慎用）配合清理。
