Composer依赖版本冲突咨询：phpunit版本不兼容问题

针对你遇到的amphp/phpunit-util要求phpunit/phpunit ^9、自研Package B要求phpunit/phpunit ^11的冲突问题，以下是可行的解决方案：

1. 升级Package A到兼容phpunit ^11的版本 #

首先检查amphp/phpunit-util是否已发布支持phpunit 11的版本：

• 执行命令：composer show amphp/phpunit-util -a，查看该包所有版本的依赖声明
• 如果存在某个版本的require字段包含phpunit/phpunit ^11（或兼容^9和11的范围，比如^9 || ^11），直接将项目中amphp/phpunit-util的版本升级到该版本，即可消除冲突。
  这是最稳妥的方案，官方维护的包通常会跟进依赖的新版本。

2. 放宽自研Package B的phpunit版本范围 #

如果你的Package B并非必须依赖phpunit 11，可以修改其composer.json中的依赖声明：

{
  "require": {
    "phpunit/phpunit": "^9 || ^11"
  }
}

修改后执行composer update，Composer会自动选择能满足所有包的最高兼容版本（或统一到^9版本，取决于其他依赖）。前提是你需要测试Package B在phpunit ^9环境下的兼容性，确保功能正常。

3. 使用Composer的replace功能模拟旧版本（有风险） #

可以通过replace字段让amphp/phpunit-util认为phpunit ^9已安装，实际运行phpunit 11：
在项目根目录的composer.json中添加：

{
  "replace": {
    "phpunit/phpunit": "9.9.9"
  }
}

• 注意：此方案属于“欺骗”依赖检测，实际运行的是phpunit 11。如果amphp/phpunit-util中使用了phpunit 9特有的API（而该API在11中已被移除或修改），会直接触发运行时错误。
• 仅建议在充分测试amphp/phpunit-util与phpunit 11的兼容性后使用，作为临时过渡方案。

4. 拆分项目结构，隔离依赖 #

若以上方案都不可行，可以将项目拆分为两个独立的Composer环境：

• 将依赖amphp/phpunit-util的代码和依赖Package B的代码分成两个子项目，各自维护自己的composer.json和vendor目录
• 或者使用Composer的工作区（workspaces）功能搭建Monorepo，让两个模块分别使用不同的phpunit版本。
  此方案能彻底隔离依赖冲突，但会增加项目结构的复杂度，适合代码逻辑相对独立的场景。

内容的提问来源于stack exchange，提问作者Jerry