composer怎么清理没用的包_composer清理冗余依赖方法

composer删包后vendor残留是正常行为，因它只更新composer.json和lock文件，物理删除需执行composer install或update触发同步；彻底清理须先移除声明，再运行composer update –with-dependencies或install，最后验证。

composer为什么删了包还留在vendor里

执行 composer remove vendor/package 后，vendor/ 目录下对应文件夹仍存在，不是 bug，是 composer 的默认行为：它只更新 composer.json 和 composer.lock，不主动清理磁盘残留。真正触发物理删除的是 composer install 或 composer update 时的“同步阶段”。

• 手动删 vendor/ 下某目录 → 下次 composer install 会把它拉回来（如果还在 composer.lock 里）
• 只改 composer.json 但不运行安装命令 → vendor/ 完全不变
• 运行 composer update --lock 不清包，它只重写 lock 文件，不碰 vendor

真正清理冗余依赖的三步操作

所谓“冗余”，指已从 composer.json 移除、但仍在 composer.lock 或 vendor/ 中残留的包。必须按顺序做：

• 确认已从 composer.json 的 require 或 require-dev 中彻底删除目标包名
• 运行 composer update --with-dependencies（推荐）或 composer install —— 前者更安全，它只更新被显式修改的依赖及其子依赖；后者强制按 lock 文件重建 vendor，更快但要求 lock 文件本身已更新
• 验证：检查 vendor/ 是否无该目录 + composer show 不再列出该包

⚠️ 注意：composer update vendor/package 是升级，不是清理；composer remove 是移除声明 + 更新 lock + 清理 vendor（v2.2+ 才默认清理），老版本需补一步 install。

composer-unused 能自动发现未使用包吗

能，但有强限制：composer-unused 是静态扫描工具，它分析代码中 use、new、class_exists 等调用，标记“声明了但没被 PHP 代码直接引用”的包。但它不理解运行时加载、配置驱动、插件机制。

• 适用场景：纯库项目、无 DI 容器、无反射调用、无配置化服务注册
• 常见误报：laravel 的 service provider、symfony 的 bundle、Doctrine 的 type 扩展、任何通过字符串类名实例化的组件
• 运行前先 composer install --no-dev，否则 dev-only 包会被误判为冗余
• 命令示例：composer unused --no-interaction --exclude=tests

清理后 vendor 还很大？可能是 autoload 陷阱

有些包体积大，但你只用了其中 1 个类，却因 autoload 配置被整包加载。比如 monolog/monolog 的 psr-4 映射覆盖整个 src/，哪怕只 use MonologLogger，Composer 也会把所有 handler、formatter 全加载进 autoloader map。

• 检查 vendor/composer/autoload_psr4.php，看目标包是否映射了过宽路径
• 无法改上游配置时，可用 composer config autoloader-suffix MyProject 强制生成独立 autoloader，减少冲突
• 极端情况可手动删 vendor 中不用的子目录（如 vendor/foo/bar/src/UnusedModule/），但下次 update 会恢复 —— 这不是持久方案，只是临时减体积

真正的轻量依赖，得靠选包时看它的 autoload 粒度，而不是清理时硬删。