答案：是循环依赖导致sat求解器无限回溯。表现为composer update --dry-run -v末行反复出现同一包路径、cpu持续95%+且内存每秒涨50mb+、composer show -t中某包出现≥3次且路径不同，实锤需用composer depends --tree查出闭环链路如myorg/core ← myorg/api ← myorg/core。

Composer 卡死、CPU 拉满、内存暴涨却无报错？这不是网络或磁盘问题，大概率是依赖图里出现了 package-a → package-b → package-a 这类强循环引用，触发了 SAT 求解器无限回溯——它不会提示“circular dependency”，只会静默死锁。

怎么确认是循环依赖而不是单纯慢？

别等 10 分钟看是否恢复。直接观察三个信号：

• 执行 composer update --dry-run -v 后，最后 10 行反复出现同一组包名（如 vendor/a → vendor/b → vendor/a）
• composer install 卡在 Resolving dependencies 超过 30 秒，top 显示 php 进程 CPU 占用持续 95%+，内存每秒增长 50MB+
• composer show -t --no-dev --ignore-platform-reqs 输出中，某个包在树里出现 ≥3 次，且每次展开路径都不同（例如 vendor/a 通过 vendor/b、vendor/c、vendor/d 三次被引入）

用 composer depends --tree 定位闭环链路

这是唯一能实锤的命令，但必须满足两个前提：项目已成功运行过 composer install（确保 composer.lock 存在），且你怀疑的包已在 lock 文件里。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 先查可疑包：比如怀疑 myorg/core 被反向拉入，运行 composer depends myorg/core --tree
• 若输出含 myorg/core ← myorg/api ← myorg/core，就是闭环实锤
• 如果报 Package not found，说明该包根本没进 lock——删掉 vendor/ 和 composer.lock，再跑 composer update --dry-run -v 看第一步失败点
• 临时注释掉 require-dev 下所有非核心工具（如 phpunit/phpunit、phpstan/phpstan），再试一次；很多“循环”只是测试包通过 autoload 加载了你的 src/

别碰 --ignore-platform-reqs 或 --force，它们只会让死锁更难定位

这些参数绕过约束检查，导致求解器尝试更多非法组合，反而延长死锁时间。真正有效的破环只有三种，且都要求改架构：

• 抽离契约包：把双方共用的接口、DTO 搬到新包 myorg/contracts，myorg/core 和 myorg/api 都只 require "myorg/contracts": "^1.0"，删掉彼此的 require
• 运行时解耦：A 不再 new B() 或 use BClass，而是定义 interface ServiceInterface（放契约包），B 实现它，A 通过容器获取实例——此时 A 的 composer.json 里彻底删掉对 B 的 require
• 降级为可选依赖：如果 B 只在 A 的测试里用（如 Mock 数据），移到 require-dev；如果是导出 Excel 这类增强功能，改用 suggest 字段提示用户手动安装

autoload 和 require-dev 的越界引用最常被忽略

你以为只是开发时用的 PHPUnit，但它可能悄悄污染了生产依赖图：

• 检查 autoload 配置：如果 "psr-4": {"App\": "src/"}，而 src/ 里用了 phpunit/phpunit 的类，Composer 就会把它当生产依赖解析
• 确认 autoload-dev 只覆盖 tests/ 或 stubs/，且命名空间不与 autoload 重叠
• 查所有 require-dev 包的 composer.json，看它们的 autoload 字段是否包含你项目的路径（如 "../src"）——这种跨项目 autoload 是隐式循环高发区
• 私有包更新后，必须运行 composer clear-cache，否则 Composer 仍拉取旧版元数据，改了也白改

真正的难点不在命令怎么敲，而在判断哪个类该放进契约包、哪个依赖该 runtime 注入——这些决策一旦定错，下次循环可能藏得更深。