Composer 遇到循环依赖直接报错中止，因依赖图存在闭环，需通过抽离契约、运行时解耦或降级为可选依赖实现单向依赖。

Composer 一见到循环依赖就直接报错中止

它不尝试解开，也不让你跳过——Dependency resolution failed: Package a depends on b, which depends on a 这类错误出现，说明依赖图里出现了闭环，Composer 立刻退出。这不是配置问题，也不是版本没选对，而是架构层面的信号：两个包不该互相“require”对方。

常见错误现象包括：

• 执行 composer update 卡在解析阶段，报错但不提示具体哪一行
• composer install 失败，提示某包“无法满足其自身依赖”
• 本地开发时能装上，CI 上失败——往往是因为缓存了旧版 composer.json 元数据

用 composer depends --tree 定位谁在拉谁

别猜，直接看依赖路径。比如你怀疑 myorg/core 被循环引入，就在项目根目录运行：

composer depends myorg/core --tree

输出里如果出现 myorg/core ← myorg/api ← myorg/core，就是实锤。注意两点：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• --tree 必须加，否则只显示一级依赖，看不到闭环
• 命令必须在已 composer install 过的项目里运行，否则依赖图不完整
• 若报 Package not found，说明该包没进 lock 文件——可能已被早期拦截，或根本没被声明

真正有效的破环方式只有三种

没有“绕过”，只有“重构”。所有靠谱方案都指向一个目标：让依赖方向变成单向。

• 抽离公共契约：把双方共用的接口、DTO、异常类拎出来，建个新包 myorg/contracts，"require": {} 保持干净；myorg/core 和 myorg/api 都只 require "myorg/contracts": "^1.0"
• 运行时解耦：A 不再 new B() 或 use BSomeClass，而是定义 interface LoggerInterface（放在契约包），B 实现它；A 通过容器或工厂获取实例——此时 A 的 composer.json 里彻底删掉对 B 的 require
• 降级为可选依赖：如果 B 只在 A 的测试里用（比如 Mock 数据），就移到 require-dev；如果是增强功能（如导出 Excel），改用 suggest 字段提示用户手动安装

容易被忽略的坑：autoload 和 require-dev 的越界引用

你以为只是开发依赖，结果它悄悄污染了主依赖图。

• 检查 autoload 配置：如果 "psr-4": {"App\": "src/"}，而 src/ 里用了 require-dev 包的类（比如 phpunit/phpunit），Composer 就会把它当作生产依赖来解析
• 确认 autoload-dev 是否只覆盖 tests/ 或 stubs/，且没和 autoload 的命名空间重叠
• 私有仓库更新后，记得 composer clear-cache，否则 Composer 仍拉取旧版元数据，改了也白改

最麻烦的情况是：循环不在你写的包里，而在你引用的第三方包之间。这时只能联系维护者，或者 fork 后临时 patch —— 但得先确认是不是真没法绕开，比如用 replace 声明自己已提供某接口。