composer循环依赖需用composer depends --tree定位闭环链路，确认后通过抽离契约包、运行时解耦或降级为可选依赖三种方式重构解决，不可跳过或强制安装。
Composer 遇到循环依赖不会尝试修复，而是直接报错退出——这不是配置或网络问题，是依赖图里出现了 A → B → A 这类闭环，必须从结构上打破。
怎么确认真是循环依赖，不是版本冲突？
报错信息里如果出现 Dependency resolution failed: Package a depends on b, which depends on a 或类似反复提及两个包互相拉取的描述，基本就是循环。但更常见的是伪装成“无法满足约束”的假象，比如：
- 执行
composer update --dry-run -v，看最后几行是否反复回溯同一组包（如vendor/a→vendor/b→vendor/a） - 运行
composer depends --tree vendor/a，输出中若出现vendor/a ← vendor/b ← vendor/a，就是实锤 - 报错里没提具体包名，但卡在
Resolving dependencies超过 30 秒，大概率是求解器在死循环里打转
用 composer depends --tree 定位闭环链路
这个命令是唯一靠谱的诊断入口，但它有严格前提：
- 必须在已成功
composer install过的项目里运行，否则依赖图不完整 - 必须加
--tree参数，只用composer depends vendor/a只显示一级依赖，看不到闭环 - 如果提示
Package not found，说明该包根本没进composer.lock，可能被早期拦截了——此时先删掉vendor/和composer.lock，再跑composer update --dry-run观察第一步失败点
查到闭环后，别急着改 require，先看它是不是由 require-dev 引入的：临时注释掉 require-dev 下所有非核心工具（比如 phpunit/phpunit、phpstan/phpstan），再试一次 composer update。很多“循环”其实只是测试工具反向加载了你的 src/。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
真正有效的破环方式只有三种
没有“跳过”“忽略”或“强制安装”，只有重构：
-
抽离契约包：把双方共用的接口、DTO、异常类拎出来，建新包
myorg/contracts，然后myorg/core和myorg/api都只require "myorg/contracts": "^1.0"，删掉彼此的require -
运行时解耦：A 不再
new B()或use BSomeClass，而是定义interface ServiceInterface（放契约包里），B 实现它，A 通过容器或工厂获取实例——此时 A 的composer.json里彻底删掉对 B 的require -
降级为可选依赖：如果 B 只在 A 的测试里用（比如 Mock 数据），就移到
require-dev；如果是增强功能（如导出 Excel），改用suggest字段提示用户手动安装
注意 autoload 和 autoload-dev 的越界引用：如果 "psr-4": {"App\": "src/"}，而 src/ 里用了 require-dev 包的类（比如 PHPUnitFrameworkTestCase），Composer 就会把它当作生产依赖来解析，形成隐式循环。
私有包、path 仓库和 replace/provide 的典型陷阱
这些地方最容易藏住隐式循环：
- 用
{"type": "path", "url": "../packages/*"}加载本地包时，如果packages/arequirepackages/b，而packages/b的composer.json里又写了"require": {"myorg/a": "dev-main"}，Composer 会优先走 path 源，立刻闭环 -
replace不是“我替代它”，而是“当我装上，Composer 就当那个包不存在”。如果app声明"replace": {"myorg/core": "*"}，而core又require app，Composer 会认为两者互斥，无法共存 - 私有包用 Satis/Toran 同步时，确保元数据生成脚本没把
require-dev也塞进 dist 包信息里——CI 上可能不暴露，但换环境立刻崩
最常被忽略的点是：你以为只是开发依赖，结果它悄悄污染了主依赖图；你以为删掉了 require，但 autoload 还在默默加载对方的类。破环不是改一行配置的事，得同时清理 require、autoload、require-dev 三处引用。
