composer install卡住且cpu飙升是因依赖求解器陷入无限回溯，主因是强循环引用（如package-a↔package-b版本范围重叠），需用composer show -t和why-not定位冲突包并修正composer.json中的不稳定约束。
composer install卡住不动，CPU飙升怎么办
这不是网络慢或磁盘满，而是依赖求解器陷入无限回溯，典型表现是终端无响应、php进程吃光 CPU、内存持续上涨。根本原因是依赖图中存在强循环引用，比如 package-a 要求 package-b:^2.0，而 package-b 又反向要求 package-a:^1.2，且两个范围有重叠。
别等它自己退出——Composer 不会报 circular dependency 错误，只会卡死。
- 先运行
composer show -t --no-dev --ignore-platform-reqs，人工扫描输出里反复出现的包名组合（如package-a → package-b → package-a） - 若树太深看不清，加
| grep -E "package-a|package-b"过滤关键路径 - 确认后，优先检查这两个包的
composer.json中require字段是否写了不稳定的分支（如dev-main、^1.5与^2.0交叉） - 临时方案：把疑似包从
require-dev移到require，或加"minimum-stability": "stable"压制 dev 版本干扰
composer why-not 显示一堆依赖链，怎么快速定位源头
composer why-not 输出的是“阻止安装”的完整路径，但真正卡点往往藏在最末端那个无法降级/升级的包。重点不是读完全部，而是找那个「版本被锁死」或「PHP 版本不匹配」的叶子节点。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer why-not vendor/package:version（例如composer why-not psr/log:3.0.0） - 看最后一行：如果结尾是
your-project-name — no constraints，说明是你自己composer.json里写了冲突的require - 如果结尾是某个第三方扩展（如
topthink/think-swoole），立刻去它的 GitHub 查composer.json和 issue，确认是否支持目标版本 - 配合
composer prohibits vendor/package:version，它比why-not更直接列出所有冲突来源，适合多点并发排查
删 composer.lock 真的能解决问题吗
不能。删 composer.lock 是最粗暴也最容易引发新问题的操作——它会让 Composer 重算整个依赖树，可能把原本稳定的老版本（比如 guzzlehttp/guzzle v7）替换成不兼容的新主版本（v8），导致运行时报错 Class GuzzleHttp\Client not found 或方法签名变化。
- 删
lock文件前，先git status确认没未提交的修改；删完立刻composer install --dry-run预览将变更哪些包 - 如果只是想验证某个包能否装上，用
composer require vendor/package:version --dry-run，不改任何文件 - 真要重算，必须搭配
--with-all-dependencies并明确接受关联变更，否则 Composer 可能拒绝执行 - 团队协作项目中，删
lock后不提交新文件，别人composer install仍会失败
require-dev 里的包偷偷拖垮生产环境
开发依赖不是“只在本地用”，只要它被其他包间接拉入（比如测试工具依赖了新版 sebastian/exporter，而该包要求 php >=8.1），就会让整个依赖解析失败，哪怕你只跑 composer install --no-dev。
- 检查
composer.json是否在require和require-dev中重复声明了同一包（如都写了phpunit/phpunit） - 把纯开发工具（如
phpstan/phpstan）移到require-dev，并加"minimum-stability": "stable" - CI/CD 流程中，确保部署命令是
composer install --no-dev --no-interaction，避免--no-dev被忽略 - 上线前运行
composer install --no-dev --dry-run，确认不会因 dev 包触发平台约束失败
依赖锁死最难缠的地方不在命令怎么写，而在冲突往往来自你看不见的地方：某个扩展的 composer.json 里写了宽松约束，某个 CI 镜像用了伪造的 PHP 版本，或者 autoload-dev 里的类被错误注册进了生产加载器。每次卡住，先停手，用 show -t 和 why-not 把隐性依赖显性化，比硬试十种 update 参数更省时间。
