推荐使用 composer remove 命令卸载包，它会自动移除 composer.json 条目、删除 vendor 目录、更新 lock 文件并重建 autoload；切勿手动删文件，否则易导致 autoload 失效或 CI 构建失败。
直接用
就行，别手动删文件
Composer 2.2+ 内置的
是唯一推荐方式——它不是“删目录”，而是“删声明 + 同步清理”，整个过程原子化：自动从
的
或
中移除条目、删除
目录、更新
、重建 autoload 映射。
常见错误现象：有人手动删掉
，再改
，结果运行
时 autoload 失效，或
仍显示已安装（因 lock 文件没更新）。
正确操作：
开发依赖也一样：
（Composer 自动识别在
里）
如果不确定包名，先查：
或打开
确认
遇到 “package is required by another package” 别硬删
这不是命令失败，是 Composer 在保护你。比如你执行
，但
正依赖它，Composer 会立刻中止并报错。
这时有两个务实选择：
接受提示，按需调整上游依赖：比如先
，再删 Guzzle；或升级到不依赖 Guzzle 的新版 Symfony 组件
临时跳过依赖检查（慎用）：
，之后手动
让 Composer 重新计算依赖树——但容易遗漏冲突，不建议日常用
强行删
条目再
，可能让 lock 文件哈希错乱，导致 CI 环境构建失败。
删完还要人工检查三件事
能清掉声明和文件，但代码里残留的引用它不管——这是最容易翻车的地方。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
搜索项目中所有
语句：
检查配置文件（如 Laravel 的
）、服务提供者、事件监听器里是否还硬编码调用了该包
运行
应返回
；
应提示
如果
后还能 new 出类，大概率是 autoload 缓存没刷新，或
的
里还留着旧路径。
全局包和彻底卸载 Composer 是另一回事
上面说的
只作用于当前项目。如果你装的是全局工具（比如
），得用：
。
而卸载 Composer 本身（不是包），是完全不同的操作：删
、清空
、删掉 shell 配置里的
引用——这些跟项目依赖无关，别混在一起处理。
最常被忽略的是：删包后没检查测试用例是否还依赖它，CI 流水线跑一半报
才发现漏了
目录下的引用。
composer removecomposer removecomposer.jsonrequirerequire-devvendor/vendor-name/package-namecomposer.lockvendor/monolog/monologcomposer.jsoncomposer installcomposer show monolog/monologcomposer remove monolog/monologcomposer remove phpunit/phpunitrequire-devcomposer show | grep monologcomposer.jsoncomposer remove guzzlehttp/guzzlesymfony/http-clientcomposer remove symfony/http-clientcomposer remove guzzlehttp/guzzle --no-updatecomposer updatecomposer.jsoninstallcomposer removeusegrep -r "use Monolog\" . --include="*.php"config/logging.phpcomposer show monolog/monologPackage not foundls vendor/monologNo such file or directorycomposer dump-autoloadcomposer.jsonautoload.filescomposer removelaravel/installercomposer global remove laravel/installer/usr/local/bin/composer~/.composerPATHClass not foundtests/