composer remove 是最稳妥的删除方式，它会卸载包、清理 vendor 文件、更新 autoload 配置并重写 composer.lock；手动删 composer.json 条目再 install 会导致残留和自动加载错误。
composer remove 会删掉依赖和自动加载配置
直接运行 composer remove vendor/package-name 是当前最稳妥的删除方式。它不只是从 composer.json 里删掉那一行，还会：卸载包本身、清理 vendor/ 目录下的文件、更新 autoload 配置（比如移除 PSR-4 映射）、重写 composer.lock。
常见错误是手动删 composer.json 里的条目再跑 composer install —— 这样 vendor/ 里残留的文件不会被清掉，自动加载器可能还留着旧映射，下次 composer dump-autoload 或运行时就容易报 Class not found 或更隐蔽的冲突。
- 必须用
composer remove，不是composer uninstall（后者根本不存在） - 如果包被其他已安装依赖间接引用，
composer remove会拒绝执行，并提示谁在依赖它；这时得先查清依赖链，不能硬删 - PHP 版本低于 7.4 的项目，
composer remove在 Composer 1.x 下不可用，只能升级到 Composer 2+ 或改用手动 +composer update
删完还要检查 autoload 和 classmap 冲突
有些包注册了 classmap 或自定义 files 加载，composer remove 虽然会清理 composer.json 里的 autoload 段，但如果你之前手动改过 autoload-dev 或在 composer.json 外写过 require_once，那些残留引用不会被自动处理。
典型现象是：包删了，但运行 composer dump-autoload 后仍报 file not found，或者测试时突然找不到某个辅助类。
- 检查
composer.json的autoload和autoload-dev字段，确认没有残留路径指向已删包的目录 - 运行
composer dump-autoload -o后，打开vendor/composer/autoload_classmap.php，搜包名或路径关键词，看是否还有未清理的映射 - 如果项目用了
files类型 autoload，删包后记得同步删掉对应文件列表，否则composer dump-autoload会因文件不存在而静默失败
dev-only 包要用 --dev 参数才真正删干净
像 phpunit/phpunit、mockery/mockery 这类只在开发环境需要的包，默认装在 require-dev 里。直接 composer remove phpunit/phpunit 会报错：“Package is not required in your composer.json.”
因为 composer remove 默认只查 require 段。不加参数就删 dev 包，等于白操作。
- 删 dev 依赖必须显式加
--dev：composer remove phpunit/phpunit --dev -
--dev和--no-dev完全不同：--no-dev是安装时用的开关，跟删除无关 - 如果同时在
require和require-dev里都写了同一个包（极少见但可能），要分两次删：先不带参数删require项，再加--dev删require-dev项
CI/CD 环境下删包后别跳过 composer install
本地删完跑一次 composer install 很自然，但 CI 脚本里常写成“删包 → 提交 → 让 pipeline 自动 install”，这就埋了坑：pipeline 用的是旧 composer.lock，而你只改了 composer.json，没生成新 lock 文件。
结果是：CI 构建成功，但实际装的仍是旧依赖树，删包等于没删；或者更糟，lock 文件校验失败直接中断。
- 删包后务必运行
composer update --lock或完整走一遍composer install，确保composer.lock同步更新 - Git 提交时，
composer.json和composer.lock必须一起提交，少一个就会导致环境不一致 - 如果项目启用了
composer install --no-interaction --no-scripts，注意某些 post-install 脚本（比如生成配置）可能因此跳过，需人工确认是否影响后续流程
