composer remove仅移除声明、vendor目录、composer.lock及autoload映射，不清理代码中的use/new、配置文件、服务提供者或运行时引用；删后须人工检查三处残留并执行dump-autoload。
composer remove 不是卸载命令的终点，而是清理工作的起点。它只管依赖声明和自动加载映射，不碰代码、配置、服务注册或运行时残留——这些必须人工扫，否则上线立刻报 Class not found 或 Driver not supported。
composer remove 会删什么、不会删什么
执行 composer remove vendor/package-name 时，它确实会：
- 从
composer.json的require或require-dev区块中移除对应条目（自动识别位置，无需加--dev） - 删除
vendor/vendor-name/package-name目录 - 更新
composer.lock并重写vendor/autoload_*.php映射文件
但它明确不会：
- 清理你代码里写的
use语句、new实例化、静态调用 - 删除框架配置文件（如 Laravel 的
config/app.php中的providers或aliases） - 移除环境变量、数据库迁移、缓存键、前端资源引用（比如
mix()加载的 JS/CSS） - 触发包自带的
post-remove脚本（极少有包真正实现）
删完必须人工检查的三处关键残留
别信 composer remove 成功就万事大吉。以下三处不手动清，CI 构建或线上部署大概率失败：
-
全局搜索包名关键词：在 IDE 或终端跑
grep -r "vendor/package-name\|package-name" . --include="*.php" --include="*.js" --include="*.env"，重点看config/、app/Providers/、routes/和.env -
查 Service Provider 和 Facade 注册：Laravel 项目务必打开
config/app.php，搜索providers和aliases数组；Symfony 项目检查config/bundles.php -
验证 Artisan 命令是否还存在：运行
php artisan list | grep -i "package-name"，若仍有输出，说明命令类没被删干净或服务提供者残留
遇到 “Package is required by another package” 怎么办
这不是错误，是 Composer 在拦你。强行绕过只会让依赖树断裂。正确做法是：
- 先查谁在用：
composer why vendor/package-name，它会列出所有直接依赖者 - 如果上游包（如
symfony/http-client）也确实不需要，就按提示先删它：composer remove symfony/http-client - 若只是临时调试，可用
composer remove vendor/package-name --no-update跳过实时解析，之后统一composer update重算依赖树（慎用，可能掩盖冲突） - 绝对不要删
composer.json后直接composer install——这会保留composer.lock里的旧哈希，CI 构建报lock file is not up to date
autoload 没刷新？别猜，直接 dump
删包后仍能 new 出来，或报 Class not found 却找不到引用点，大概率是 autoloader 缓存没更新。尤其在 Docker、CI 或启用了 --classmap-authoritative 的环境里：
- 先补一句：
composer dump-autoload - 如果项目用了优化模式（Laravel 9+ 默认开启），必须加参数：
composer dump-autoload --classmap-authoritative -
vendor/autoload.php是入口，但它背后依赖vendor/composer/autoload_classmap.php等生成文件，删包不等于这些文件自动重写
最常被忽略的是：composer remove 完全不管 config/ 里那些硬编码的驱动名、中间件别名、甚至 phpunit.xml 里的测试套件路径——这些不人工核对，问题一定出现在上线后第一分钟。
