应使用 composer remove 卸载包,它会自动删 composer.json 条目、删 vendor 目录、更新 composer.lock 并重建 autoload 映射;手动删文件或改配置易致 autoload 错乱、类找不到及锁文件哈希不一致。

直接用 composer remove,别删 vendor 目录或手改 composer.json —— 这是唯一安全、原子化的卸载方式。
为什么不能手动删 vendor 或改 composer.json
手动删 vendor/monolog/monolog 再删 composer.json 里那行,接着跑 composer install,看似干净,实则埋雷:
-
composer.lock里的哈希没更新,CI 构建可能失败 -
vendor/autoload.php仍保留旧的类映射,运行时突然报Class not found却不提示来源 - 子依赖(如
psr/log)可能残留,变成“幽灵包”,后续composer update会意外升级它
composer remove 的实际行为是什么
它不是“删文件”,而是执行一次反向安装:自动识别包在 require 还是 require-dev 中,然后同步做四件事:
- 从
composer.json对应区域删除条目 - 删除
vendor/vendor-name/package-name目录 - 更新
composer.lock,重算所有依赖版本 - 重建 autoload 映射(等价于自动执行
composer dump-autoload)
整个过程失败即回退,不会留下半截状态。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
遇到 “Package is required by another package” 怎么办
这不是错误,是 Composer 在拦你——说明你想删的包被其他已装包硬依赖。比如执行 composer remove guzzlehttp/guzzle,但 symfony/http-client 明确 require 它,就会中止并提示谁在引用。
- 先查依赖链:
composer why guzzlehttp/guzzle - 若确认上游也不需要,可一起删:
composer remove symfony/http-client,再删 Guzzle - 若只是临时调试,加
--no-update跳过实时重装,之后手动composer update让 Composer 重新收敛依赖树(慎用) - 想连带清理只被该包引用的子依赖(如
guzzlehttp/promises),加--with-dependencies
删完还要做什么
composer remove 只管声明和文件,不管你的代码。
- 全局搜
use Monolog:grep -r "use Monolog\" . --include="*.php"(注意反斜杠转义) - 检查配置文件(如 Laravel 的
config/logging.php)、服务提供者、app/Providers/里是否还注册了该包 - 运行
composer show monolog/monolog应返回Package not found - 确认
ls vendor/monolog报No such file or directory - 如果
new MonologLogger还能执行,大概率是autoload.files里留了旧路径,或缓存没刷干净,再跑一次composer dump-autoload -o
最常翻车的地方,永远是代码里那一行没删掉的 use 或配置项。










