在 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会处理，但若中断过可能残留）
