composer remove比手动删composer.json更可靠，因其执行反向安装逻辑，自动校验依赖图谱、移除未被复用的传递依赖，并提供删除预览；手动删除后仅composer install不触发依赖重解析，易留僵尸依赖。
直接删 composer.json 里的包名，再跑 composer remove，不是最安全的做法——它不检查依赖树是否真被切断，容易留僵尸依赖或破坏间接依赖。
为什么 composer remove 比手动删 require 更可靠
手动从 composer.json 删除包后执行 composer install，Composer 只会卸载该包，但不会主动降级或调整其子依赖；而 composer remove 会模拟一次“反向安装”，递归计算整个依赖图谱，移除该包及其未被其他包复用的传递依赖。
- 它调用的是和
composer require对称的解析逻辑，能识别哪些包是“仅被目标包引用”的 - 如果某子依赖（比如
psr/log）同时被你保留的monolog和待删的guzzlehttp/guzzle引用，它就不会动这个psr/log - 执行前会输出将要删除的完整包列表，给你二次确认机会
composer remove 的实际执行流程与常见卡点
运行 composer remove vendor/package-name 后，Composer 会先锁定当前 composer.lock，再尝试构建一个不含该包的新依赖图。失败通常出现在：
- 该包被其他已安装包硬性要求（例如
laravel/framework依赖symfony/console，你却想删symfony/console）→ 报错Root package 'xxx' cannot be removed because it is required by another package. -
composer.lock过期或损坏 → 先运行composer update --lock再试 - 你删的是开发依赖（
require-dev），但命令没加--dev标志 → 它默认只操作require，必须显式写composer remove --dev phpunit/phpunit
删完之后必须验证的三件事
别以为命令成功退出就万事大吉。真实项目里，废弃组件常以“静态调用”“配置文件引用”“服务提供者注册”等形式残留。
- 搜代码里是否还有
use、new、class_exists等对该包类名的引用（特别是vendor/autoload.php被 include 的地方） - 检查
config/app.php（Laravel）或services.yaml（Symfony）等配置文件，删掉对应的服务提供者或扩展配置 - 运行
composer show确认包名彻底消失；再跑一次composer outdated，看有没有因依赖链断裂导致的版本冲突警告
真正麻烦的从来不是删包本身，而是那些没写在 composer.json 里、却活在 app/ 目录下对旧包的隐式调用——它们不会报错，只会在某个边缘路径里突然抛出 Class not found。
