composer 遇到循环依赖直接报错，不尝试绕过也不提供跳过选项；它用 sat 求解器识别依赖环，认为这是架构缺陷，唯一解法是重构依赖为单向，如抽离契约包、运行时解耦或调整 require-dev。
Composer 遇到循环依赖直接报错，不尝试绕过也不给你跳过选项
Composer 一看到 A → B → A 这类闭环，立刻中止解析并报错，比如：Root package cannot be installed 或 Package a depends on b, which depends on a。这不是版本没选对，也不是缓存问题，而是它明确拒绝参与“逻辑上不可能”的依赖图构建。
- 它用 SAT 求解器分析依赖，能识别环，但不会尝试“破环”或降级处理——设计上就认为这是架构缺陷信号
- 哪怕两个包版本明明兼容（如
A ^1.5和B ^2.0），只要依赖图里存在路径闭环，就会失败 - 错误常卡在
Resolving dependencies阶段几十秒后才抛出，不是立即崩溃，容易误判为网络或性能问题
用 composer depends --tree 定位真实闭环路径
别猜谁引了谁，直接看依赖树。命令必须在已成功 composer install 的项目里运行，否则依赖图不完整，--tree 是关键，否则只显示一级依赖，看不到闭环。
- 查可疑包：例如怀疑
myorg/core被循环引入，运行composer depends myorg/core --tree - 实锤闭环的输出长这样：
myorg/core ← myorg/api ← myorg/core—— 箭头方向是“被谁依赖”，出现自身两次即闭环 - 如果报
Package not found，说明该包没进composer.lock，可能早被解析阶段拦截，需先清理缓存再试：composer clear-cache
真正有效的破环只有三种，没有“绕过”，只有重构
所有靠谱方案都指向一个目标：让依赖方向变成单向。临时删 require-dev 或加 --ignore-platform-reqs 只能掩盖问题，不能解决。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
抽离公共契约：把共用的接口、DTO、异常类拎出来建新包（如
myorg/contracts），它的composer.json中"require": {}应为空；core和api都只require "myorg/contracts": "^1.0" -
运行时解耦：A 不再
new B()或use BClass，而是定义LoggerInterface（放契约包），B 实现它，A 通过容器获取实例；此时 A 的composer.json里必须删掉对 B 的require -
降级为可选依赖：B 只在 A 的测试中用？移到
require-dev；是增强功能（如导出 Excel）？改用suggest字段提示用户手动安装
最容易被忽略的隐式循环：autoload + require-dev 组合陷阱
最常被漏掉的不是 require 互引，而是开发依赖通过自动加载“悄悄加载了你的代码”，而你的代码又用了它的类，形成逻辑循环。
- 检查所有
require-dev包的composer.json，重点看它们的autoload字段是否包含你项目的目录（如"../src"或"../../myproject/src"） - 确认
autoload-dev只覆盖tests/或stubs/，且命名空间不与主autoload重叠（例如主 autoload 是{"psr-4": {"App\": "src/"}}，就别让 dev autoload 也映射App\） - 私有包用 Satis/Toran 同步后，记得
composer clear-cache——旧元数据还在缓存里，改了composer.json也白搭
闭环往往不在表面 require 里，而在 autoload 路径、dev 包的加载行为、私有仓库元数据同步延迟这些地方。一旦出问题，先清缓存、再砍 require-dev、最后查 --tree，比盯着报错信息空想快得多。
