如何解决Composer的user包与captcha包之间的循环依赖问题

你当前的实现方案不合理，会直接形成user包和captcha包的硬循环依赖，完全违背了拆分为独立Composer包的核心目的：两个包将无法独立安装、独立发布、独立做单元测试，也无法单独给其他项目复用，后续任意一个包的版本迭代都可能引发另一个包的兼容故障。

你可以根据自身业务场景选择以下几种方案解决反向依赖问题：

• 抽离公共契约层
  新增独立的第三方契约包，两个业务包同时依赖这个契约包：在契约包中定义CaptchaValidatorInterface（验证码校验相关方法）、UserAdminInterface（管理员权限相关方法）两个接口。user包和captcha包都只依赖接口调用能力，不依赖具体实现，具体的实例注入由上层的主项目完成，从根本上解除两个包的互相依赖。
• 事件驱动解耦
  在user包的认证、注册流程的对应位置抛出前置事件，不需要直接引入captcha包的代码；captcha包自行监听user包抛出的这些事件，在校验不通过时抛出异常中断流程即可。captcha包依赖的管理员权限能力也可以通过服务容器动态获取，仅需要在composer.json的suggest字段声明用到权限功能时需要安装user包，不需要做硬依赖声明。
• 合并包（仅适合内部私有包场景）
  如果这两个包本来就是仅用于内部特定项目，没有对外开源或者给其他无关项目复用的需求，直接将两个包合并为一个统一的用户认证公共包即可，反而会降低拆分过细带来的维护成本。

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