直接运行 composer remove 即可安全卸载依赖包，它会自动删除 vendor/ 目录下对应包、从 composer.json 的 require 或 require-dev 中移除条目，并更新 composer.lock 和剩余依赖。
直接运行 composer remove 就能安全卸载依赖包，不需要手动删 vendor/ 或改 composer.json —— 但必须注意它只移除当前项目顶层声明的包，不处理间接依赖。
用 composer remove 卸载指定包
这是 Composer 2.2+ 内置命令，会自动：删 vendor/ 下对应目录、从 composer.json 的 require（或 require-dev）里移除条目、重装剩余依赖并更新 composer.lock。
常见用法：
- 卸载生产环境依赖：
composer remove monolog/monolog - 卸载开发依赖：
composer remove phpunit/phpunit --dev - 一次卸载多个：
composer remove doctrine/orm symfony/console
执行后检查 composer.json 是否已清理干净，避免残留字段引发后续安装异常。
为什么不用 composer uninstall 或 composer delete
这些命令根本不存在 —— Composer 没有 uninstall 子命令，旧版用户误用 composer update --no-install + 手动删 vendor/ 极易导致锁文件与实际目录不一致，下次 composer install 可能意外拉回已“卸载”的包。
真正安全的流程只有两个入口：
- 顶层包：用
composer remove - 间接依赖（如 A 依赖 B，你只卸了 A）：等下次
composer update自动清理，或显式运行composer update --with-dependencies触发级联更新
卸载后仍报 Class not found？检查 autoload 配置
有些包在卸载后仍被加载，往往是因为：
-
composer.json的autoload或autoload-dev里还留着已删包的psr-4映射 - 项目代码里有硬编码的
require_once或include指向vendor/路径 - OPcache 未清除，缓存了旧的类名到文件路径映射
解决方法：删掉 autoload 区块中对应条目 → 运行 composer dump-autoload → 清 PHP OPcache（如 opcache_reset() 或重启 Web 服务）。
想彻底清理没声明但实际存在的包？别直接删 vendor/
如果 vendor/ 里有没写在 composer.json 中的目录（比如手动 git clone 进去的），composer remove 不会碰它，但 composer install 也不会保留它 —— 它属于“脏状态”。正确做法是：
- 确认是否真不需要：查 Git 历史或项目文档
- 若确定废弃：先删该目录，再运行
composer validate确保composer.json无语法错误，最后composer install重建干净依赖树
强行手动删 vendor/ 子目录而不更新 composer.lock，会导致下次部署时行为不可预测。
