composer remove 会卸载指定包及其未被其他依赖引用的子依赖、清理 vendor/ 对应目录、更新 composer.lock，但不删除手动代码、配置、迁移文件或回滚插件逻辑。
composer remove 会删掉哪些东西
执行 composer remove 不只是从 composer.json 里删掉包名，它还会：卸载该包及其所有未被其他依赖引用的子依赖、清理 vendor/ 对应目录、更新 composer.lock。但不会碰你手动写的代码、配置文件或数据库迁移——这些得自己处理。
常见错误现象：composer remove foo/bar 后运行报错 class not found，往往是因为你还留着 use FooBarSomething; 或调用了它的方法，而类文件已被删了。
- 只删包本身和“孤儿”依赖（即没有其他包 require 它的那些）
- 不会自动删除
config/、migrations/、resources/等目录下该包生成的文件 - 如果包注册了 Composer 插件（如
extra.installer-paths），插件逻辑不会回滚，得手动清理
remove 命令必须带包名，不能只写 vendor
composer remove 后面必须跟完整的 vendor/package 格式，比如 laravel/sanctum，不能写成 laravel 或 sanctum —— 否则报错 Package "laravel" is not installed。
使用场景：你想删掉一个包，但不确定它在 composer.json 里叫什么名字？先运行 composer show 查列表，或者直接看 composer.json 的 require 或 require-dev 字段。
- 支持一次删多个：例如
composer remove laravel/sanctum spatie/laravel-permission - 不支持通配符，
composer remove laravel/*会失败 - 如果包在
require-dev里，remove默认只查require；加--dev才能删开发依赖：composer remove --dev phpunit/phpunit
删包后 autoload 没更新？检查 autoload 配置残留
有些包会在 composer.json 的 autoload 或 autoload-dev 里加自定义路径（比如 "psr-4": {"Foo": "src/Foo/"}）。composer remove 不会动这些配置，但对应目录可能已不存在，导致下次 composer dump-autoload 报警告，甚至运行时报 Cannot redeclare class 或找不到类。
性能影响：残留的无效 autoload 规则会让 Composer 加载器多扫几个不存在的路径，虽不致命，但在大型项目里会拖慢 CLI 命令启动速度。
- 删包后，手动打开
composer.json，检查autoload和autoload-dev是否还挂着已删包的命名空间或路径 - 删掉无用规则后，务必运行
composer dump-autoload生效 - 如果项目用了
classmap，也得同步清理对应条目，否则composer install可能静默失败
遇到 “Package is not installed” 却明明在 composer.json 里
典型原因是：包被锁在 composer.lock 里，但没实际下载到 vendor/（比如之前 composer install 中断过，或删过 vendor/ 但没重装）。这时 composer remove 会说没装，但 composer.json 还有记录。
兼容性影响：这种情况多见于 CI 环境或团队协作中 lock 文件和 vendor 不一致，强行删会导致本地和线上行为不一致。
- 先运行
composer install补齐 vendor，再composer remove - 或者跳过校验：用
composer remove --no-install foo/bar，它只改composer.json和composer.lock，不验证 vendor 状态 - 更稳妥的做法是：先
git diff composer.json确认改动意图，再操作，避免误删还在用的包
最常被忽略的是 autoload 配置和 migration 文件——它们不会随 remove 自动消失，但又不像类那样报错明显，容易埋雷到上线后才暴露。