Composer 依赖解析基于 SAT 求解器，只处理版本约束与包间指向关系，不识别调用方向或架构层级；反向依赖属代码层问题，需通过抽离契约、运行时解耦或降级为 dev 依赖等代码重构解决，无法靠配置阻断。
Composer 没有“依赖层级限制器”这个功能，也不存在能靠配置阻断反向调用的开关——所有试图在 composer.json 里加个字段就防住循环依赖的做法，都会失败。
为什么“配置层级限制”根本行不通
Composer 的依赖解析基于 SAT 求解器，它只认版本约束和包间指向关系，不理解“调用方向”“运行时耦合”或“架构层级”。你在 composer.json 里写 "require": {"myorg/api": "^2.0"}，它只负责确保这个包能装上、版本满足、哈希校验通过；至于你的 MyOrgCoreSomeService 类里是不是 new ApiClient()、是不是 use MyOrgApiDtoResult，它完全不管。
所谓“非正常反向调用”，本质是代码层的架构污染，不是依赖声明层的问题。配置再严，也拦不住 src/ 里一行 use 或一个 new。
- 所有声称能“配置阻止反向依赖”的插件或自定义脚本，最终都只是在
composer install后跑静态分析（比如 PHPStan），属于事后检查，不是 Composer 本身的能力 -
autoload-dev里误写"../src/"这种隐式循环，composer validate和composer install都不会报错——它合法，只是危险 - 你加
"minimum-stability": "stable"或"prefer-stable": true，只能压制 dev 分支引入的不稳定版本，对a → b → a的稳定版闭环毫无作用
真正能定位反向调用链的命令只有 composer depends --tree
这是目前唯一能暴露闭环路径的官方命令，但它有硬性前提：项目必须已成功执行过 composer install，且 composer.lock 完整存在。否则输出为空或报 Package not found。
实操要点：
- 先确认目标包已安装：
composer show myorg/core能查到，再跑composer depends myorg/core --tree - 重点看输出中是否出现自指路径，例如
myorg/core ← myorg/api ← myorg/core—— 箭头方向是“被谁依赖”，同一包名出现两次即闭环实锤 - 如果输出太长，用
grep过滤：composer depends myorg/core --tree | grep -E "(myorg/core|myorg/api)" - 别只信
composer depends myorg/core（无--tree），它只显示一级上游，漏掉 A→C→B→A 这类间接环
阻断反向调用只能靠代码层重构，不是 Composer 配置
破环没有捷径，只有三种可落地的结构改造方式，全部发生在代码和 composer.json 的协同调整中：
-
抽离契约：把共用的接口、DTO、异常类拆成新包（如
myorg/contracts），它的composer.json中"require": {}必须为空；core和api都只require "myorg/contracts": "^1.0" -
运行时解耦：删掉
core中对api的require，改用容器注入ApiClientInterface（该接口放在contracts包里）；此时core的composer.json里不能出现myorg/api -
降级为可选：如果
api只在core的测试中使用，就把它从require移到require-dev；如果是导出 Excel 这类增强功能，改用suggest字段提示用户手动安装
最容易被忽略的破环点：临时注释掉 require-dev 下所有喜欢跨项目 autoload 的工具（比如 infection/infection、phpstan/phpstan 插件），它们常在自己的 composer.json 里写 "autoload": {"psr-4": {"App\": "../src/"}}，等于把你的 src/ 加进它的自动加载路径，而你的代码又用了它的类，形成运行时闭环。
真正难的不是找到循环，而是说服团队接受“删掉 require”这个动作——因为那行 new ApiClient() 看起来那么自然，直到它让整个 CI 卡死三分钟、CPU 拉满、composer update 报错信息滚动一屏还找不到关键包名。
