composer如何递归删除依赖_composer依赖清理工具【笔记】

不会。composer remove 只移除显式指定的包及其在 composer.json 中的直接声明，不递归清理因其他包被删而变成“孤儿”的间接依赖，残留包仍留在 vendor/ 和 composer.lock 中。

composer remove 会自动删掉未被引用的依赖吗

不会。composer remove 只移除你显式指定的包，以及它在 composer.json 中的直接声明；它**不递归清理**那些因其他包被删而变成“孤儿”的间接依赖（即未被任何已安装包 require 的包）。这些残留包仍留在 vendor/ 里，也会继续出现在 composer.lock 中。

常见错误现象：composer remove monolog/monolog 后，vendor/psr/log 还在——因为别的包（比如 symfony/console）可能仍依赖它；但如果你先删了所有上层包，psr/log 却没被自动剔除，那就是“残留”。

• 执行 composer remove 后，务必运行 composer install 或 composer update --lock 来同步 lock 文件和 vendor
• 想确认是否真有孤儿包？可临时删掉 vendor/ 和 composer.lock，再跑 composer install——这才是最干净的基线
• composer update --dry-run 能预览哪些包会被升级或卸载，但不反映“完全无引用”的孤儿包

手动递归清理依赖的可靠做法

Composer 本身没有内置 “–recursive-prune” 这类开关。所谓“递归删除”，本质是：先确保 composer.json 只保留你真正需要的 root 包，再让 Composer 重新计算整个依赖图并重装。

实操建议：

• 逐个执行 composer remove 清掉不需要的 root 依赖（别用 require 写死在 json 里又不删）
• 检查 composer.json 的 require-dev，开发依赖常被忽略，但它们同样会拖入大量传递依赖
• 删完后运行 composer update --with-all-dependencies，强制刷新整棵树（比单纯 install 更彻底）
• 如果想激进一点：删掉 vendor/ + composer.lock，再 composer install——这是最接近“从零重建依赖图”的方式

第三方工具能替代手动清理吗

目前没有被广泛采纳、稳定维护的“Composer 依赖清理器”。有些脚本或小工具（如 composer-unused）能帮你发现未被代码引用的包，但它判断的是「php 类是否被 use/import」，不是「是否被其他 composer 包依赖」——这两者完全不同。

例如：composer-unused 可能报告 guzzlehttp/promises “未使用”，但它可能是 aws/aws-sdk-php 的子依赖，删了会导致 SDK 报错。

• composer-unused 适合优化 autoloading 和 dev 依赖，不适合生产环境依赖树裁剪
• composer show --tree 是最可靠的依赖关系视图，用它人工确认某包是否真无上级引用
• 避免使用未经验证的 bash/python 小脚本批量删 vendor/ 下目录——容易破坏 autoload 机制或引发 class not found

为什么不能直接删 vendor/ 下的文件夹

因为 Composer 的自动加载器（vendor/autoload.php）和类映射（vendor/composer/autoload_*.php）是根据 composer.lock 和安装时的包结构生成的。手动删目录会导致：

• autoload 文件里仍有该包的 PSR-4/ClassMap 记录，但文件已不存在 → 运行时报 Class not found
• composer dump-autoload 不会自动剔除已丢失的包注册项
• composer install 也不会恢复缺失的包，除非 composer.lock 里还记着它

所以，“删文件夹”永远不该是清理手段。唯一安全路径是：改 composer.json → composer update 或重装。