Composer怎么检测冗余依赖_Composer未用包排查方法【实用】

很多PHP开发者都遇到过这样的困惑：composer.json里塞了一堆包，到底哪些是真正用上的？直接告诉你答案：Composer本身并不提供检测冗余依赖的功能。目前最靠谱的方案是composer-unused——它不看你composer.json里写了什么，而是直接扫描你的PHP代码，看有没有实际use、new、class_exists过某个包里的类。静态分析，只认硬引用，不碰运行时动态加载。需要留意的是，它给出的结果可能存在误报，得人工再过一遍。

直接结论：Composer 本身不检测冗余依赖，composer-unused 是目前最可靠、可落地的方案——它不看 composer.json 里写了什么，只看你的 PHP 代码里是否真实 use、new、class_exists 过某个包里的类。

为什么 composer show / composer outdated 都不能用来找未使用包

composer show 只列出已安装的包及其版本信息；composer outdated 只对比当前锁定版本和远程可用版本。两者都不扫描源码，完全不涉及“是否被调用”这个维度。

常见误判现象：

• 某个包只在 require-dev 中声明，但项目里一行 use 都没有 → composer show 仍显示它已安装，outdated 可能还提示它可升级
• 你删掉了所有 use MyVendorSomeClass，但没删 composer.json 里的 "myvendor/some-package": "^2.0" → 这些命令毫无反应
• 框架配置（如 Symfony 的 config/packages/foo.yaml）引用了某包，但无 PHP 类调用 → composer-unused 会标为未使用，而其他命令根本看不见这层关系

怎么正确运行 composer-unused 扫描项目

必须先确保 vendor/ 完整（composer install 已执行），否则 autoload 映射缺失，会导致大量误报。

安装与基础运行：

• 推荐全局安装：composer global require composer-unused/composer-unused
• 确认 ~/.composer/vendor/bin/ 在 $PATH 中，再运行：composer-unused --no-progress
• 默认只扫 src/，若你的主逻辑在 app/ 或 lib/，必须显式指定：composer-unused --path=app --path=lib
• 测试文件默认被跳过，但如果你的包仅在 *Test.php 中被 use，需加：--include-tests

注意：v0.12.x 要求 PHP ≥ 8.1；PHP 7.4 项目必须降级到 v0.9.11，否则因 readonly 语法报错。

哪些情况会被误标为“未使用”，该怎么处理

composer-unused 是静态分析工具，对运行时行为无感知。以下三类场景极易误报，需人工介入：

• 动态类名加载：$class = 'MyVendor\SomeClass'; new $class(); → 不会识别，建议白名单
• 注解驱动（如 doctrine/annotations）或 DI 容器配置（如 Lara vel Service Provider 中的 bind()）→ 没 use，但实际被反射调用
• 仅在 CI 脚本（如 .github/workflows/test.yml）或 IDE 插件中使用的 require-dev 包（如 phpunit/phpunit）→ 源码层确实没引用，标记正确，但你不该删

解决方式：在项目根目录建 composer-unused.php，写入白名单：

 [
        'doctrine/annotations',
        'phpunit/phpunit',
        'myvendor/my-runtime-extension'
    ]
];

路径排除也常用：--exclude tests --exclude vendor --exclude var，避免 vendor 内部引用污染结果。

真正容易被忽略的是：它不分析 ext-* 扩展依赖（如 ext-gd）、不解析 YAML/JSON 配置中的服务引用、也不跟踪 class_alias 或 call_user_func。这些都得靠人眼判断，工具只负责把“确定没被 PHP 源码显式引用”的包列出来——剩下的，是你的责任。