很多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 源码显式引用”的包列出来——剩下的，是你的责任。
