卡在 resolving dependencies 且 cpu 拉满，基本是递归依赖冲突；须用 composer update --dry-run -v 确认闭环循环，重点看末尾路径是否重复跳转，再结合 composer depends --tree 定位隐式闭环链路。
卡在 Resolving dependencies 且 CPU 拉满、终端无响应，基本可以确定是递归依赖冲突，不是网络慢或镜像问题——这时候等再久也没用，得立刻切到诊断模式。
用 composer update --dry-run -v 确认是否闭环循环
这是唯一能实锤“死循环”的入口。加 -v 是硬性要求，不加就只显示“正在解析”，什么也看不到。
- 重点看输出末尾几行：如果反复出现同一组路径跳转，比如
vendor/a → vendor/b → vendor/a，出现两次就是闭环实锤 - 若只报
Recursion limit exceeded (200)且无包名路径，大概率是深度爆炸，不是闭环 - Windows 下 cmd 可能截断输出，建议用 PowerShell 或加
| more分页查看 - 输出里若出现
Package not found，说明该包根本没进解析阶段，先composer clear-cache，再删vendor/和composer.lock重试
用 composer depends --tree 定位闭环链路
这个命令不是可选项，是必须项，但它有两个硬前提：项目已成功执行过 composer install（保证 composer.lock 有完整快照），且必须带 --tree 参数。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不加
--tree就只显示一级依赖，根本看不到间接环 - 运行
composer depends vendor/package-name --tree，输出中若出现vendor/package ← vendor/other ← vendor/package，箭头方向是“被谁依赖”，自身出现两次即闭环 - 别只盯着
require，重点查require-dev引入的包是否悄悄污染了主依赖图——比如phpunit/phpunit的autoload里写了"../src/"，就把你的src/加进了它的自动加载路径；而你的代码又用了它的测试基类，运行时就形成隐式闭环 - 所有
require-dev包的composer.json都要搜../、../../、src/这类路径；同时检查你自己的autoload-dev是否误把vendor/下的路径写进去了——这等于告诉 Composer：“我依赖我自己”
避免删 composer.lock 后盲目重装
composer.lock 不是缓存，是契约：它明确记录每个包的精确版本、哈希值、下载源和依赖拓扑。直接删掉再跑 composer install，会让 Composer 重算整个依赖树，极大概率导致生产环境行为漂移。
- 删
composer.lock是引入新问题的开关，不是解法 - 如果
composer.lock已损坏或手动编辑过，优先用composer update --dry-run -v验证当前状态是否可收敛，再决定是否重建 - 真正需要重装时，应先
git stash或备份当前composer.lock，再删再装，并立刻验证关键功能是否正常
最隐蔽的闭环往往藏在 autoload 和 require-dev 的交叉引用里，而不是 require 明面上的版本约束中。盯住这两处，比调 process-timeout 或换镜像管用得多。
