答案：是循环依赖导致sat求解器无限回溯。表现为composer update --dry-run -v末行反复出现同一包路径、cpu持续95%+且内存每秒涨50mb+、composer show -t中某包出现≥3次且路径不同，实锤需用composer depends --tree查出闭环链路如myorg/core ← myorg/api ← myorg/core。
Composer运行时CPU拉满，不是网络卡、也不是磁盘慢，大概率是依赖解析器在本地穷举版本组合——尤其当composer.json里用了"*"或"^1.0 || ^2.0"这类宽泛约束时，求解时间会从秒级跳到分钟级，CPU持续95%+，内存每秒涨50MB+。
怎么确认是循环依赖导致CPU卡死
别等它自己恢复。直接看三个信号：
- 执行
composer update --dry-run -v后，末尾10行反复出现同一组包路径（如myorg/core → myorg/api → myorg/core） -
top里php进程CPU长期95%+，且free -h显示可用内存每秒掉50MB+ -
composer show -t输出中，某个包在依赖树里出现≥3次，且每次展开路径都不同（比如通过vendor/a、vendor/b、vendor/c三次被引入）
用composer depends --tree实锤闭环链路
这个命令是唯一能定位循环依赖的工具，但有两个硬前提：
- 项目必须已成功跑过
composer install（确保composer.lock存在） - 你怀疑的包得已在
lock文件里；如果composer depends myorg/core --tree报Package not found，说明它根本没进锁，先删vendor/和composer.lock，再跑composer update --dry-run -v看第一步在哪崩
一旦输出含myorg/core ← myorg/api ← myorg/core，就是闭环实锤。临时解法是注释掉require-dev下所有非核心工具（比如phpunit/phpunit），很多“循环”其实是测试类通过autoload反向加载了src/。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
低配VPS上必须禁用的三个东西
不是“建议关”，是不关就稳不住：
-
Xdebug：它会让依赖解析慢5–10倍。临时禁用命令是php -d zend_extension= -d xdebug.mode=off /usr/bin/composer install -
--ignore-platform-reqs和--with-all-dependencies：它们绕过缓存，强制全量重算，不是提速，是让求解器尝试更多非法组合，延长死锁时间 - 旧版插件（如
fxp/composer-asset-plugin）：已废弃，严重干扰解析流程；加--no-plugins显式禁用
composer install卡在Installing dependencies怎么办
这个阶段卡住，90%和依赖解析无关，是下载或解压问题：
- 并发数太高：默认
parallel-downloads=20对512MB VPS是灾难。全局设成composer config -g parallel-downloads 4 - 镜像源没清缓存：换阿里云源
https://mirrors.aliyun.com/composer/后，必须立刻composer clear-cache，否则旧包仍走packagist.org - PHP 8.2+别开
opcache.enable_cli=1：CLI场景下它反而拖慢Composer自身加载
真正容易被忽略的是：循环依赖不会报错，也不会写日志，只静默死锁——你看到的“卡住”，大概率是SAT求解器在无限回溯，而不是在等网络或磁盘。定位前先停掉所有可能干扰的扩展和参数，不然越调越偏。
