直接删掉不用的包最有效；require-dev、replace、provide、minimum-stability和prefer-stable等字段会悄悄扩大依赖图，需结合composer depends、grep代码及手动检查配置文件、类引用和autoload映射来识别并清理幽灵依赖。

直接删掉不用的包，比调任何参数、换任何镜像都管用。Composer 本身不压缩依赖图，它只忠实执行约束；所谓“降低解析复杂度”，本质是人工剪枝+约束收敛。

哪些 composer.json 字段会悄悄扩大依赖图

很多人只盯着 require，但以下字段同样触发安装或干扰解析逻辑：

• require-dev：所有开发依赖（如 phpunit/phpunit、phpstan/phpstan）全参与依赖图构建，哪怕你只在 CI 中跑测试
• replace：不下载包，但会让 Composer 认为某个虚拟包（如 psr/log）已被满足，从而跳过更轻量的实现，选中一个带额外依赖的替代包
• provide：多个包同时 provide 同一个接口（如 cache-implementation），可能让解析器陷入更多分支尝试
• minimum-stability 设为 "dev" 或关闭 prefer-stable：强制开启不稳定分支搜索，大幅增加候选版本数和回溯深度

用 composer depends 和 grep 判断“幽灵依赖”

有些包出现在 vendor/ 里，只是因为某条深层传递链带进来的，项目代码根本没用它：

Discussion Composer

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

下载

• 运行 composer depends monolog/monolog —— 如果返回空，说明没有直接依赖它，它是被间接拉入的
• 再搜项目代码：grep -r "use Monolog\" src/、grep -r "Monolog\\Logger" config/、grep -r "'Monolog\\Logger'" app/
• 特别注意配置文件、事件监听器、队列任务里的字符串类名，它们不会被 IDE 的 “Find Usages” 捕获

remove 后必须手动清理的三处残留

composer remove foo/bar 只删包和 require 行，以下地方常被忽略：

• 框架配置文件（如 Laravel 的 config/app.php 中的 providers 或 aliases）
• 所有 use 语句，以及硬编码在数组、配置值、字符串拼接中的类名（比如 'fooBarClient'）
• 旧的 autoload 映射：必须运行 composer dump-autoload -o，否则 Class not found 错误会指向已删除包里的路径，找不到源头

真正难的不是命令怎么敲，而是判断某个包是否“隐式强依赖”——比如一个日志驱动，看似只是 laravel/framework 的传递依赖，但如果你在 config/logging.php 里自定义了它的通道，那它就是业务必需项。这类边界，得看运行时调用栈，不能只靠静态分析。