Composer如何卸载或移除不需要的扩展包

在 PHP 项目中管理依赖时，Composer 的卸载操作其实是个容易出坑的地方。很多人习惯直接去 vendor/ 目录删文件，或者手动改 composer.json，但这样做往往后患无穷。下面拆解几个关键环节，帮你把这件事办得干净利落。

直接用 composer remove，别手动删 vendor/ 或改 composer.json

Composer 2.2+ 之后，内置的 composer remove 命令就是最靠谱的选择——它不是简单地删文件，而是执行一次完整的反向安装流程：自动识别包在 require 还是 require-dev 中、移除对应条目、删除 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程是原子化的，失败即回退，不会留下半截状态。

很多人会犯这样的错误：先手动删掉 vendor/monolog/monolog 目录，再跑去 composer.json 里删掉那行声明，最后跑 composer install——结果 autoload 找不到类，composer show monolog/monolog 还显示已安装（因为 composer.lock 没同步），CI 构建也报哈希不一致。另一种常见情况是只改 composer.json 后运行 composer install，这可能导致版本漂移，尤其当 composer.lock 里存了精确哈希时。

正确做法就是一条命令：

composer remove monolog/monolog

它会自动判断包所在的位置，无需加 --dev（除非同名包同时出现在两个区）。

遇到 “package is required by another package” 别硬删

这不是报错，而是 Composer 的保护机制在起作用。比如你执行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确依赖它，Composer 就会中止并告诉你谁在用。强行绕过只会埋下隐患。

• 查依赖链：运行 composer why guzzlehttp/guzzle，输出会列出所有直接引用者
• 接受提示降级或移除上游包（按 y 确认），比如先 composer remove symfony/http-client，再删 Guzzle
• 临时调试可以用 --no-update 跳过实时解析：composer remove guzzlehttp/guzzle --no-update，之后再 composer update（慎用，可能遗漏冲突）

删完必须人工扫三处残留

composer remove 只管声明和 autoload 配置，但你的代码里可能还留着大量 use 语句、new 调用、配置项或服务提供者注册。这些不清理干净，上线就等着 Class not found 的报错吧。

• 全局搜 use 语句：grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义）
• 检查配置文件：比如 Lara vel 的 config/logging.php、Symfony 的 config/packages/monolog.yaml 是否还引用该包
• 确认服务提供者：app/Providers/ 或 config/app.php 里是否注册了对应的 ServiceProvider
• 额外检查：composer.json 的 autoload.files 或 autoload.psr-4 是否硬写了该包路径

删完 autoload 没刷新？立刻补 composer dump-autoload

极少数情况下，composer remove 执行成功但类仍能 new 出来，或者报 Class not found 却查不到哪里引用——这大概率是 autoloader 缓存没及时更新，尤其在 Docker 或某些 CI 环境里更容易出现。

• 强制重建映射：composer dump-autoload
• 如果用了优化模式（如 --classmap-authoritative），记得加参数重生成：composer dump-autoload --classmap-authoritative
• Lara vel 用户还要清 config 缓存：php artisan config:clear，否则旧的 service provider 可能还注册着已删包的逻辑
• 检查 vendor/composer/autoload_*.php 文件里是否还存在该包的路径声明（正常情况下 remove 会处理，但若中断过可能残留）