推荐使用 composer remove 卸载包，它自动移除依赖项、更新锁文件并重建自动加载；手动删文件或改配置易致 autoload 错乱、类找不到或哈希不一致。
直接用 composer remove，别手删 vendor/ 或改 composer.json
Composer 2.2+ 内置的 composer remove 是唯一推荐方式——它不是“删文件”，而是执行一次受控的反向安装：自动从 composer.json 的 require 或 require-dev 中移除条目、删除 vendor/vendor-name/package-name 目录、更新 composer.lock、重建自动加载映射。整个过程原子化，失败即回退。
- 错误做法：手动删
vendor/guzzlehttp/guzzle，再手动删composer.json里那行，最后跑composer install→ 极易导致 autoload 错乱、类找不到、锁文件哈希不一致 - 正确命令：
composer remove guzzlehttp/guzzle（自动识别在require还是require-dev，无需加--dev） - 想只改配置不重装？加
--no-update：composer remove spatie/laravel-backup --no-update，后续统一composer install
卸载失败报 “required by another package” 怎么办
这不是报错，是 Composer 的保护机制。比如你删 guzzlehttp/guzzle，但 symfony/http-client 明确声明了对它的依赖，Composer 就会中止并告诉你谁在用它。
- 查依赖链：
composer why guzzlehttp/guzzle，输出会列出所有直接引用者 - 如果上游包（如
symfony/http-client）你也确定不用了，按提示确认降级或连带移除 - 临时清理子依赖？加
--with-dependencies：composer remove guzzlehttp/guzzle --with-dependencies，可顺手删掉guzzlehttp/promises这类只被它引用的包 - 硬删
composer.json再composer install？可能触发意外版本漂移，尤其当composer.lock里有精确哈希时
卸载后类还能 new 出来，或报 Class not found 却搜不到引用
大概率是 autoload 缓存没刷新，尤其在 Docker、CI 环境或 Laravel 9+ 启用了 --classmap-authoritative 的项目里。删包 ≠ 自动加载映射立刻更新。
- 强制刷新：
composer dump-autoload --classmap-authoritative（Laravel 9+ 默认启用，不加参数可能无效） - 清 Composer 自身缓存：
composer clear-cache（尤其之前用过镜像源异常或--no-cache） - 检查
vendor/composer/autoload_psr4.php或autoload_classmap.php是否还残留路径（正常情况remove会处理，但中断过可能卡住） - 确认
composer.json的autoload.files或autoload.psr-4里没硬写该包路径
全局插件怎么卸载，和项目依赖别搞混
全局包（如 laravel/installer、phpunit/phpunit）装在用户主目录下（~/.composer/vendor/ 或 ~/.config/composer/vendor/），不能用普通 composer remove，必须加 global。
- 查已装全局包：
composer global show - 卸载命令：
composer global remove laravel/installer - 验证是否干净：
composer global show不再出现该包，并手动检查~/.composer/vendor/bin/下对应可执行文件是否已删（有时残留会导致命令还能运行） - 别在项目根目录下误跑
composer global remove—— 它不会报错，但会默默操作全局环境，容易误伤
最常被忽略的不是命令本身，而是卸载后的代码扫尾：use 语句、配置项、服务提供者注册、数据库迁移、缓存键——这些 composer remove 一律不管，全靠你 grep 和人工判断。
