如何删除不再使用的Composer依赖包

在维护 PHP 项目的过程中，清理那些不再使用的依赖包，是件既简单又容易出岔子的苦差事。你可能觉得，删掉 composer.json 里的那一行就万事大吉了？如果真是这样，那大概率会留下后患。事实上，很多开发者踩过的坑，都源于“只删了声明，却没同步底层文件”——结果 vendor/ 目录里包还在，自动加载映射还记着旧类路径，运行时要么报 Class not found，要么悄无声息地加载失败。

直接运行 composer remove 是最安全的方式

对于 Composer 2.2 及以上版本，官方推荐的方式就是直接用 composer remove 命令。它一次性搞定三件事：从 composer.json 中移除包名、卸载包并更新锁文件、刷新自动加载映射。相比手动编辑 JSON 再跑 composer update，这要靠谱得多，能有效避免依赖残留或自动加载器报错。 一个常见的错误现象是：只删了 composer.json 里的条目，却忘了跑 composer update，结果 vendor/ 目录里包还在，autoload_classmap.php 仍保留着旧类路径，运行时要么报 Class not found，要么悄无声息地加载失败。

• 执行 composer remove monolog/monolog（支持多个包，空格分隔）
• 如果提示 Command "remove" is not defined，说明 Composer 版本太低，先升级：composer self-update
• 若该包被其他已安装包依赖，remove 会失败并提示冲突，此时需先查清依赖链：composer depends monolog/monolog

手动删除后必须运行 composer update --lock

如果你的 Composer 版本低于 2.2，或者需要对锁文件变更进行精细控制，那就得手动操作了。但关键在于，不是“删哪行”，而是“删完怎么同步 vendor 和 lock”。只改 composer.json 不触发重新安装，vendor/ 和 composer.lock 就会不一致，后果就是各种怪异的错误。 这种场景常见于 CI 环境锁定特定版本、团队强制要求 lock 文件变更可追溯、或要排除某个包的 transitive dependency 但保留其主包。

• 编辑 composer.json，从 require 或 require-dev 中删掉对应包行（注意逗号，别破坏 JSON 格式）
• 立即运行 composer update --lock（不是 install），它只更新 lock 文件，不碰 vendor；再补一次 composer install 清理 vendor
• 若跳过 --lock 直接 composer install，可能因 lock 文件还记着旧包而静默恢复安装

composer outdated 能帮你发现“僵尸依赖”

很多包其实早就不用了，但没人记得删。这类“僵尸依赖”不会报错，却会拖慢安装速度、增加攻击面、干扰 IDE 自动补全。靠人工检查代码很难全覆盖，用 composer outdated 加上 --direct 选项是个不错的起点。 从性能角度看，每个未用的包都会参与自动加载器生成、PSR-4 映射扫描，以及某些框架的编译缓存构建。积少成多，会显著延长 CLI 命令和 Web 请求的冷启动时间。

• 运行 composer outdated --direct --minor-only，列出所有有更新的直接依赖，顺手检查哪些根本没在代码里 use 过
• 用 grep -r "use.*PackageName" app/ src/ --include="*.php" 快速验证是否真被引用（注意别漏掉别名 use A as B）
• 删之前，建议在疑似调用点加个临时的 die('xxx used here');，跑一遍测试或请求，确认没有实际调用再动手

删包后别忘了检查 autoload 和配置文件残留

有些包会注册全局服务提供者（比如 Lara vel 的 providers 数组）、自定义自动加载器（如 files 数组），或者在 .env 里写死配置项。这些不会随 composer remove 自动清理，但一旦包没了，就会在启动时报错。 容易被忽略的地方包括：框架的配置合并逻辑中，某个文件可能 require 了已删包的类；PHP 扩展级钩子，比如 APCu 缓存中还存有该包的序列化对象；甚至 Docker 构建缓存里残留的 vendor 层。

• 搜索项目根目录：grep -r "monolog" config/ app/ bootstrap/ --include="*.php" --include="*.env"
• 检查 composer.json 的 autoload 和 autoload-dev 字段，删掉已失效的 psr-4 映射或 files 引用
• 运行 composer dump-autoload 确保新 autoloader 生效，再试 php -m | grep apcu 看扩展是否还试图加载旧类

删包本身并不复杂，难的是确认它真的没有被任何地方间接依赖——包括测试代码、部署脚本，甚至 CI 中某个废弃 job 的临时 require。每次删完，最好在干净环境里跑一次全量测试：rm -rf vendor composer.lock && composer install，确保一切正常。