应使用 composer remove 命令安全卸载包，它自动移除声明、删除文件、更新锁文件和 autoload 映射；手动删 vendor 或 composer.json 易致 autoload 错乱、版本不一致；需人工清理代码中 use、配置、服务注册等残留。
直接用 composer remove，别手删 vendor 或改 json
Composer 2.2+ 内置的 composer remove 就是专为安全卸载设计的，它不是“删文件”，而是执行一次反向安装：自动从 composer.json 的 require 或 require-dev 中移除条目、删除 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程原子化，失败即回退。
常见错误现象：有人手动删掉 vendor/monolog/monolog，再删 composer.json 里那行，最后跑 composer install——这极容易导致 autoload 错乱、类找不到，或锁文件版本不一致。
-
composer remove monolog/monolog—— 自动识别在require还是require-dev，无需加--dev（除非同名包同时出现在两个区） - 想跳过实时重装？加
--no-update：只改composer.json，后续再统一composer update - 执行后立刻检查：
composer show monolog/monolog应报 “Package not found”
遇到 “required by another package” 别硬删
这是保护机制，不是报错。比如你运行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确声明了对它的依赖，Composer 就会中止并提示谁在依赖它。
这时候不能靠删配置硬来，得看清楚依赖链：
- 查谁在用：
composer why guzzlehttp/guzzle，输出会列出所有直接引用者 - 若确实不需要上游包（如
symfony/http-client），可接受 Composer 提示的降级/移除建议（按 y 确认） - 若只是临时调试，可用
--with-dependencies让 Composer 连带清理“只被该包引用”的子依赖（如guzzlehttp/promises） - 切忌先删
composer.json再composer install，可能触发意外版本漂移
删完还要人工扫代码，autoload 不会帮你擦屁股
composer remove 只管依赖声明和自动加载配置，不管你的 PHP 文件里还留着多少 use、new、配置项或服务提供者注册。这些残留不清理，上线就 Class not found。
- 全局搜索关键词：
grep -r "Monolog\" . --include="*.php"（注意转义反斜杠） - 检查
config/下的配置文件（Laravel/Symfony 项目常见）、app/Providers/里的服务注册 - 运行
composer dump-autoload -o强制刷新映射，避免缓存误导判断 - 如果之前在
composer.json的autoload.files或autoload.psr-4里硬写了该包路径，也要手动删掉
全局包要用 composer global remove，别在项目里瞎敲
很多人在某个 Laravel 项目根目录下输 composer remove laravel/installer，结果发现没反应或者删错了项目依赖——因为 laravel/installer 是全局安装的工具，必须走全局命令。
- 正确命令：
composer global remove laravel/installer - 验证是否清干净：
composer global show，列表里不应再出现 - 删完仍能执行
laravel new？说明二进制还在$PATH里，检查~/.composer/vendor/bin/或 shell 配置里的export PATH=...行 - 别用
rm -rf ~/.composer/vendor/laravel手动删，可能漏掉 autoload 和配置项
最常被忽略的一点：卸载不是终点，是清理链条的第一环。包删了，代码里调用没删；依赖解除了，配置文件里开关还开着；composer.json 干净了，config/logging.php 里还写着 'driver' => 'monolog'——这些地方不亲手过一遍，卸载就等于埋雷。
