composer如何卸载某个依赖包？（正确移除方法）

composer remove 是最干净的卸载方式，它会删除 vendor 目录对应包、更新 autoload 映射、重写 composer.lock，并自动执行清理逻辑；若包在 require-dev 中需加 –dev 参数；laravel 项目还需手动清理 service provider 和 facade。

composer remove 会真正删掉包和自动加载配置

直接运行 composer remove vendor/package-name 是当前最干净的卸载方式。它不只是删 composer.json 里的条目，还会：自动执行 composer install 阶段的清理逻辑，移除 vendor/ 下对应目录，更新 autoload 映射（包括 PSR-4、classmap 等），并重写 composer.lock。

• 别手动删 composer.json 中的 "require" 行再跑 composer install —— 这样 vendor/ 里残留的文件可能还在，且 autoload_classmap.php 或 autoload_psr4.php 里还存着旧类路径，导致运行时报 Class not found
• 如果包同时出现在 require 和 require-dev，composer remove 默认只处理 require；要删 dev 包，得加 --dev 参数：composer remove --dev phpunit/phpunit
• 卸载后检查 vendor/autoload.php 是否仍能正常加载其他类 —— 有时某些包的卸载会意外触发 autoload 生成失败（尤其用了自定义 classmap 的老项目），此时可手动运行 composer dump-autoload

卸载后 class 还能 new 出来？可能是 autoload 没刷新

常见现象：执行了 composer remove foo/bar，但代码里 new FooBarSomeClass() 仍不报错。这通常不是包没删干净，而是 vendor/composer/autoload_*.php 文件里还残留着该类的映射，或项目用了 classmap 方式加载且未重建缓存。

• 确认 vendor/foo/bar/ 目录已不存在
• 检查 vendor/composer/autoload_psr4.php 和 autoload_classmap.php，搜索包名或类前缀，看是否还有残留条目
• 强制重建 autoload：composer dump-autoload --optimize（注意：–optimize 会合并所有映射，适合生产环境；开发中用 composer dump-autoload 即可）
• 某些 IDE（如 phpstorm）会缓存类索引，卸载后需手动 File → Reload project from Disk 或清空索引

依赖被其他包间接引用时，remove 会失败

如果目标包是另一个已安装包的子依赖（比如你装了 monolog/monolog，它 require psr/log），直接 composer remove psr/log 会报错：Package psr/log is not required in your composer.json and has not been removed 或更明确的冲突提示。

• 先查依赖树：composer depends psr/log（Composer 2.2+）或 composer show -t psr/log
• 若确实只是被间接引用，不用主动卸载 —— 它由父包控制生命周期；强行删会导致父包功能异常
• 想彻底去掉某个传递依赖，只能升级/降级或替换它的直接依赖方（例如换一个不依赖 psr/log 的日志库）
• 极少数情况需要“强制断开”，可用 composer require --no-update psr/log:dev-master 再 composer update psr/log --with-dependencies，但风险高，不推荐

卸载 Laravel package 要额外清理 service provider 和 facade

Laravel 场景下，仅 composer remove 不够。很多包会在 config/app.php 注册 providers 或 aliases，这些不会被 Composer 自动清理，残留会导致启动时报 Class not found 或服务解析失败。

• 手动检查 config/app.php，删掉对应的 providers 数组项（如 FooBarServiceProvider::class）和 aliases 里的 facade（如 'Bar' => FooBarFacade::class）
• 有些包带 uninstall 命令（如 php artisan vendor:publish --provider="FooBarServiceProvider" --force 的逆操作），但极少；优先看包文档的 “uninstallation” 小节
• 运行 php artisan config:clear 和 php artisan cache:clear，避免配置缓存干扰

实际卸载动作很简单，麻烦的是后续验证和周边清理。最容易被忽略的是 autoload 缓存残留和 Laravel 配置项，这两处不处理，问题会延迟到第一次请求才暴露。