composer remove 会卸载包、删除 vendor 中对应目录、更新 composer.lock 并重生成自动加载，但不清理框架配置文件；需手动移除 service providers、aliases 等引用，否则运行时报错。
composer remove 会删掉哪些东西
执行 composer remove 不只是从 composer.json 里删掉包名，它还会：卸载包本身、清理 vendor/ 下对应目录、更新 composer.lock、触发自动加载重生成。但不会动你手动写的 config/app.php 或其他框架配置——那些得自己清理。
常见错误现象：composer remove foo/bar 成功了，但运行时仍报 Class not found，大概率是残留了服务提供者注册、门面别名或配置文件引用。
- 只删依赖不删配置 → 启动报错或功能异常
- 批量删多个包时，如果它们之间有依赖关系（比如 A 依赖 B），
composer remove A B会按拓扑顺序处理，但建议先删上层再删底层，避免中间状态混乱 - 某些包（如 Laravel 的官方扩展）卸载后可能留空配置键，导致
config:cache失败
一次删多个包的正确写法
直接在命令行里空格连写多个包名即可，不需要写多次 remove：
composer remove spatie/laravel-permission laravel/sanctum nunomaduro/collision
这条命令等价于逐个执行，但更高效，且 composer.lock 只更新一次。注意：所有包必须已安装在当前项目中，否则会报 Package "xxx" is not installed，但不会中断整个命令 —— 其余包照常卸载。
- 包名大小写敏感，
spatie/laravel-permission≠Spatie/Laravel-Permission - 不要加
v或版本号，composer remove foo/bar:^2.0会报错，版本约束只在require时有效 - 如果某个包被其他已装包依赖，
composer会拒绝删除，并提示冲突 —— 这不是 bug，是保护机制
删完还要手动检查什么
Composer 不管你的代码里是否还调用了被删包的类、方法或配置项。最容易漏的是：
-
config/app.php里的providers和aliases数组（Laravel 场景） -
app/Providers/AppServiceProvider.php中的use语句和boot()里对第三方类的调用 -
routes/web.php或routes/api.php中的中间件引用（如middleware('permission:...')） - PHPStorm 或 VS Code 的缓存没清，导致“找不到类”红标还在，其实已经删干净了
一个快速验证方式：php artisan config:clear && php artisan cache:clear && composer dump-autoload，再跑一遍 php artisan tinker，试试 class_exists('Spatie\Permission\PermissionRegistrar') 是否返回 false。
想彻底清空 vendor 重装怎么办
这不是“卸载依赖”，而是重建环境。适用场景：怀疑依赖损坏、锁文件混乱、或想切换 PHP 版本后重装所有包。
- 先删
vendor/和composer.lock：rm -rf vendor composer.lock（Windows 用rmdir /s vendor && del composer.lock） - 再运行
composer install—— 它只装composer.lock里记录的版本；没有 lock 文件时，install会退化为update，可能装新版，行为不可控 - 如果真要“重装但保持旧版本”，别删
composer.lock，只删vendor/再composer install
这个操作看起来像卸载，但实际是重建，和 remove 的语义完全不同。误删 composer.lock 后又没提交过，就很难还原到上次部署的精确状态。
