composer remove 是最安全的卸载方式，它自动移除 composer.json 条目、删除 vendor 中代码、更新 lock 文件；手动删配置后必须运行 composer install，否则 autoload 失效、vendor 残留。
composer remove 会自动删 composer.json 和卸载包
直接运行 composer remove vendor/package-name 是当前最安全、最推荐的做法。它不是只删配置，而是完整反向执行 composer require：先从 composer.json 移除对应条目，再卸载已安装的代码（删 vendor/ 下对应目录），最后重装依赖并更新 composer.lock。
常见错误是手动编辑 composer.json 后不运行 composer install 或 composer update，结果导致 vendor/ 里还留着旧包、autoload 失效、甚至运行时报 Class not found。
- 如果包被其他依赖间接引用，
composer remove会拒绝操作，并提示冲突 —— 这是保护机制，别硬删composer.json - 删的是
require区域的包；如果是require-dev里的，得加--dev参数：composer remove --dev phpunit/phpunit - PHP 版本或平台约束不满足时，
remove可能卡在依赖解析阶段，可临时加--ignore-platform-reqs（仅调试用）
手动删 composer.json 条目后必须跑 composer install
有人习惯打开 composer.json 直接删掉某一行 "monolog/monolog": "^2.0"，以为完事了。其实这只是“半步” —— vendor/ 没清、自动加载没刷新、composer.lock 还记着它。
手动改完必须立刻执行：composer install（推荐）或 composer update vendor/package-name。前者按当前 composer.lock 重装，更快更稳；后者会重新解析依赖树，可能连带升级其他包。
- 删的是根项目依赖，不是子依赖：比如你没直接 require
symfony/polyfill-php81，它是被symfony/console拉进来的 —— 手动删它没用，composer install会把它加回来 - 删完不执行命令，
composer show仍会列出该包，vendor/目录也还在，容易误判“已删干净” -
composer update全量执行太重，尤其大项目，容易意外升级次要版本引发兼容问题
删包后 autoload 失效？检查 vendor/autoload.php 是否被缓存或硬引入
即使 composer remove 成功、vendor/ 里没了文件、composer.json 也干净了，有些老项目仍报 Class not found。大概率是代码里写了死路径引入，绕过了 Composer 自动加载机制。
典型问题包括：require 'vendor/autoload.php' 写在了不该写的地方（比如框架入口外的工具脚本）、或用了 include_once 硬加载某个已删除包的类文件。
- 搜索整个项目有没有
require/include包含vendor/路径的语句，尤其是部署脚本、测试启动文件 - 检查
composer dump-autoload -o是否被误执行过 —— 优化后的 autoloader 缓存可能残留旧映射，删vendor/composer/autoload_*.php再重生成即可 - 某些 IDE（如 PHPStorm）会缓存类索引，删包后需手动
File → Reload project from Disk
CI/CD 流水线里删包要小心 composer install --no-interaction 的行为
自动化环境里用 composer remove 可能失败，因为它的交互式确认默认开启。CI 脚本里必须加 -n（即 --no-interaction），否则卡住超时。
更稳妥的做法是：先 composer remove -n vendor/package-name，再 git add composer.json composer.lock 提交变更 —— 这样下次 CI 拉代码后只需 composer install，不依赖 remove 命令。
- Git 提交前务必检查
composer.json和composer.lock是否同步更新，CI 不会帮你补漏 - 若用 Docker 构建镜像，
vendor/是构建阶段产物，删包后必须重建镜像，不能靠 volume 挂载“热删” - 某些私有仓库配置了 token 或 auth.json，
remove过程中若触发依赖重解析，可能因认证失败中断
vendor/ 是否真空了、autoload 是否重新生效、还有没有哪段代码在黑暗角落里偷偷 require 着它。 
