应使用 composer remove 卸载包，它会自动删除声明、清理 vendor、更新 lock 文件并重建 autoload；手动删文件或改配置易致 autoload 错乱、类找不到及锁文件哈希不一致。
直接用 composer remove，别手删 vendor/ 或硬改 composer.json
Composer 2.2+ 内置的 composer remove 是唯一推荐方式——它不是“删文件”，而是执行一次反向安装：自动识别包在 require 还是 require-dev 里、删条目、删 vendor/vendor-name/package-name 目录、更新 composer.lock、重建 autoload 映射。整个过程原子化，失败即回退。
常见错误现象：
- 手动删掉
vendor/monolog/monolog，再删composer.json里那行，最后跑composer install—— 结果autoload找不到类、composer show monolog/monolog还显示已装（因composer.lock没同步更新）、CI 构建也可能报哈希不一致 -
composer remove monolog/monolog执行后ls vendor/monolog仍存在目录 —— 多半是命令中途被中断，或之前用了--no-update却忘了后续composer update
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确认包名：先运行
composer show | grep monolog或打开composer.json查看全称 - 开发依赖也一样：如
phpunit/phpunit，composer remove phpunit/phpunit会自动识别它在require-dev里，无需加--dev（除非同名包同时出现在两个区） - 想跳过实时重装？加
--no-update：只改composer.json，后续统一composer update
遇到 “required by another package” 别硬删，这是保护机制
这不是命令失败，是 Composer 在阻止你破坏依赖图。比如你执行 composer remove guzzlehttp/guzzle，但 symfony/http-client 明确依赖它，Composer 就会中止并告诉你谁在用。
实操建议：
- 查谁在依赖它：
composer why guzzlehttp/guzzle，输出会列出所有直接引用者 - 若上游包（如
symfony/http-client）也确实不需要，就一起删：composer remove symfony/http-client guzzlehttp/guzzle - 临时调试想绕过检查？慎用
--no-update，之后composer update可能漏掉冲突，不推荐日常操作 - 绝对避免先删
composer.json条目再composer install，容易触发版本漂移，尤其锁文件有精确哈希时
删完必须人工扫代码，composer remove 不管 use、配置和注册
composer remove 只管声明和 autoload 配置，不管你的 PHP 文件里还留着多少 use MonologLogger、new Logger()、Laravel 的 config/logging.php 配置，或者 app/Providers/LoggingServiceProvider.php 里的注册逻辑。这些残留不清理，上线就 Class not found。
实操建议：
- 全局搜索关键词：
grep -r "use Monolog\" . --include="*.php"（注意反斜杠转义） - 检查
config/下配置文件、服务提供者、事件监听器是否硬编码调用了该包 - 运行
composer show monolog/monolog应返回Package not found；ls vendor/monolog应提示No such file or directory - 如果
composer dump-autoload后还能new出类，大概率是 autoload 缓存没刷新，或composer.json的autoload.files里还留着旧路径
autoload 没刷新？重点检查这三处
删完跑起来报 Class not found，大概率不是删失败，而是 autoloader 没生效。Composer 的自动加载分三层，每层刷新逻辑不同：
-
composer dump-autoload只重新生成vendor/autoload_*.php，不碰vendor/composer/autoload_*.php - 真正影响类加载的是
vendor/composer/autoload_classmap.php和autoload_psr4.php，它们只在composer install或composer update时重写 - Laravel 用户还要清 config 缓存：
php artisan config:clear，否则旧的 service provider 可能还注册着已删包的逻辑
特别注意：Laravel 9+ 默认开启 classmap-authoritative，删包后不 dump-autoload 就会卡在旧映射里；Docker 或 CI 环境里 autoload 缓存可能更顽固，必要时加 --optimize 或重启 PHP 进程。
