--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/guzzle v6.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（慎用）配合清理。

# php  # 的是  # 只会  # 用了  # 报错  # 它会  # 要小心  # 它不  # 这三个  # 旧版  # console  # require  # js  # git  # json  # composer  # 作用域  # 为什么  # symfony  # 参数作用域  # 你该