Composer怎么删除依赖项 Composer怎么移除不再用包【操作】

composer remove 是最稳妥的删除方式，它会卸载包、清理 vendor 文件、更新 autoload 配置并重写 composer.lock；手动删 composer.json 条目再 install 会导致残留和自动加载错误。

composer remove 会删掉依赖和自动加载配置

直接运行 composer remove vendor/package-name 是当前最稳妥的删除方式。它不只是从 composer.json 里删掉那一行，还会：卸载包本身、清理 vendor/ 目录下的文件、更新 autoload 配置（比如移除 PSR-4 映射）、重写 composer.lock。

常见错误是手动删 composer.json 里的条目再跑 composer install —— 这样 vendor/ 里残留的文件不会被清掉，自动加载器可能还留着旧映射，下次 composer dump-autoload 或运行时就容易报 class not found 或更隐蔽的冲突。

• 必须用 composer remove，不是 composer uninstall（后者根本不存在）
• 如果包被其他已安装依赖间接引用，composer remove 会拒绝执行，并提示谁在依赖它；这时得先查清依赖链，不能硬删
• PHP 版本低于 7.4 的项目，composer remove 在 Composer 1.x 下不可用，只能升级到 Composer 2+ 或改用手动 + composer update

删完还要检查 autoload 和 classmap 冲突

有些包注册了 classmap 或自定义 files 加载，composer remove 虽然会清理 composer.json 里的 autoload 段，但如果你之前手动改过 autoload-dev 或在 composer.json 外写过 require_once，那些残留引用不会被自动处理。

典型现象是：包删了，但运行 composer dump-autoload 后仍报 file not found，或者测试时突然找不到某个辅助类。

• 检查 composer.json 的 autoload 和 autoload-dev 字段，确认没有残留路径指向已删包的目录
• 运行 composer dump-autoload -o 后，打开 vendor/composer/autoload_classmap.php，搜包名或路径关键词，看是否还有未清理的映射
• 如果项目用了 files 类型 autoload，删包后记得同步删掉对应文件列表，否则 composer dump-autoload 会因文件不存在而静默失败

dev-only 包要用 –dev 参数才真正删干净

像 phpunit/phpunit、mockery/mockery 这类只在开发环境需要的包，默认装在 require-dev 里。直接 composer remove phpunit/phpunit 会报错：“Package is not required in your composer.json.”

因为 composer remove 默认只查 require 段。不加参数就删 dev 包，等于白操作。

• 删 dev 依赖必须显式加 --dev： composer remove phpunit/phpunit --dev
• --dev 和 --no-dev 完全不同：--no-dev 是安装时用的开关，跟删除无关
• 如果同时在 require 和 require-dev 里都写了同一个包（极少见但可能），要分两次删：先不带参数删 require 项，再加 --dev 删 require-dev 项

CI/CD 环境下删包后别跳过 composer install

本地删完跑一次 composer install 很自然，但 CI 脚本里常写成“删包 → 提交 → 让 pipeline 自动 install”，这就埋了坑：pipeline 用的是旧 composer.lock，而你只改了 composer.json，没生成新 lock 文件。

结果是：CI 构建成功，但实际装的仍是旧依赖树，删包等于没删；或者更糟，lock 文件校验失败直接中断。

• 删包后务必运行 composer update --lock 或完整走一遍 composer install，确保 composer.lock 同步更新
• git 提交时，composer.json 和 composer.lock 必须一起提交，少一个就会导致环境不一致
• 如果项目启用了 composer install --no-interaction --no-scripts，注意某些 post-install 脚本（比如生成配置）可能因此跳过，需人工确认是否影响后续流程

删包这事看着简单，真正麻烦的是 autoload 残留、dev 标记遗漏、lock 文件不同步这三处——它们都不报错，但会在某个深夜部署时突然让你多盯半小时日志。