推荐使用 composer remove 命令卸载包，它会自动移除 composer.json 条目、删除 vendor 目录、更新 lock 文件并重建 autoload；切勿手动删文件，否则易导致 autoload 失效或 CI 构建失败。
直接用 composer remove 就行，别手动删文件
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 show monolog/monolog 仍显示已安装（因 lock 文件没更新）。
- 正确操作：
composer remove monolog/monolog - 开发依赖也一样：
composer remove phpunit/phpunit（Composer 自动识别在require-dev里） - 如果不确定包名，先查：
composer show | grep monolog或打开composer.json确认
遇到 “package is required by another package” 别硬删
这不是命令失败，是 Composer 在保护你。比如你执行 composer remove guzzlehttp/guzzle，但 symfony/http-client 正依赖它，Composer 会立刻中止并报错。
这时有两个务实选择：
- 接受提示，按需调整上游依赖：比如先
composer remove symfony/http-client，再删 Guzzle；或升级到不依赖 Guzzle 的新版 Symfony 组件 - 临时跳过依赖检查（慎用）：
composer remove guzzlehttp/guzzle --no-update，之后手动composer update让 Composer 重新计算依赖树——但容易遗漏冲突，不建议日常用
强行删 composer.json 条目再 install，可能让 lock 文件哈希错乱，导致 CI 环境构建失败。
删完还要人工检查三件事
composer remove 能清掉声明和文件，但代码里残留的引用它不管——这是最容易翻车的地方。
- 搜索项目中所有
use语句：grep -r "use Monolog\" . --include="*.php" - 检查配置文件（如 Laravel 的
config/logging.php）、服务提供者、事件监听器里是否还硬编码调用了该包 - 运行
composer show monolog/monolog应返回Package not found；ls vendor/monolog应提示No such file or directory
如果 composer dump-autoload 后还能 new 出类，大概率是 autoload 缓存没刷新，或 composer.json 的 autoload.files 里还留着旧路径。
全局包和彻底卸载 Composer 是另一回事
上面说的 composer remove 只作用于当前项目。如果你装的是全局工具（比如 laravel/installer），得用：composer global remove laravel/installer。
而卸载 Composer 本身（不是包），是完全不同的操作：删 /usr/local/bin/composer、清空 ~/.composer、删掉 shell 配置里的 PATH 引用——这些跟项目依赖无关，别混在一起处理。
最常被忽略的是：删包后没检查测试用例是否还依赖它，CI 流水线跑一半报 Class not found 才发现漏了 tests/ 目录下的引用。
