composer remove是安全卸载起点，它自动删声明、vendor目录、更新lock与autoload，但不清理代码中use语句、配置、服务注册及子依赖，须人工处理，否则运行时报错。
用 composer remove 卸载包是唯一安全的起点，但它不会自动清理代码里残留的 use、配置、服务注册或子依赖——这些必须手动处理，否则运行时直接报错。
为什么不能只删 vendor/ 目录下的文件夹
手动删 vendor/some-package 看似快，但会立刻破坏 Composer 的状态一致性：
-
composer dump-autoload仍会读取旧的 autoload 映射，导致Class not found或加载错误类 -
composer show和composer depends依赖composer.lock和实际安装状态，删文件不更新锁文件，输出完全不可信 - 包自带的 uninstall 脚本（如 Laravel 的 service provider 注销逻辑）根本不会触发
-
vendor/composer/autoload_classmap.php这类底层映射文件不会自动刷新，缓存残留引发偶发性加载失败
composer remove 实际做了什么、没做什么
它执行的是原子化反向安装流程：删 composer.json 条目 → 删 vendor/ 对应目录 → 更新 composer.lock → 重写 autoload 文件 → 运行 uninstall 脚本（如有）。
但它明确不管这些：
- PHP 文件里的
use SomePackageFoo或new Foo() -
config/app.php中的providers、aliases数组项（Laravel 场景） - 服务提供者里对第三方类的调用（如
AppServiceProvider::boot()） - 路由中间件、事件监听器、Artisan 命令类等硬编码引用
验证是否真删干净：运行 composer show some-package/some-package 应报 “Package not found”，再 ls vendor/some-package 应提示 “No such file or directory”。
怎么确认一个包真的“不再使用”，而不仅是没写在 require 里
composer remove 只响应你显式指定的包名，它不扫描项目代码是否还在调用。要判断“是否真不用了”，得靠人工+工具交叉验证：
- 全局搜索类名：例如删
guzzlehttp/guzzle，就跑grep -r "GuzzleHttp\" . --include="*.php"（注意反斜杠转义） - 查框架配置：
grep -r "guzzle" config/ --include="*.php"，重点看services.php、logging.php等 - 检查谁在依赖它：
composer why guzzlehttp/guzzle，若输出为空，说明没其他已装包硬依赖它 - 注意别名陷阱：有些包在
composer.json里写的是"monolog/monolog": "^3.0"，remove 时必须输全名，不能只输monolog
子依赖和“孤儿包”怎么清干净
composer remove 会自动删掉“仅被该包引用”的子依赖（比如 guzzlehttp/promises），但前提是它们没被其他已安装包共享。
如果你怀疑有历史遗留的“孤儿包”（即既没写在 composer.json，也没被任何已装包依赖），唯一可靠方式是重建 vendor：
- 备份当前
vendor（可选）：mv vendor vendor.bak - 删掉整个
vendor和composer.lock：rm -rf vendor composer.lock - 重新安装：
composer install—— 它只装composer.json显式声明的包及其必需子依赖 - 对比
vendor.bak和新vendor，消失的包就是真正的孤儿
别用 composer update 替代：它会保留 composer.lock 里的旧包，无法剔除孤儿。
