composer-unused是目前最可靠方案，它仅通过静态扫描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 映射缺失，会导致大量误报。
安装与基础运行：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐全局安装：
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 容器配置（如 Laravel Service Provider 中的bind()）→ 没use，但实际被反射调用 - 仅在 CI 脚本（如
.github/workflows/test.yml）或 IDE 插件中使用的require-dev包（如phpunit/phpunit）→ 源码层确实没引用，标记正确，但你不该删
解决方式：在项目根目录建 composer-unused.php，写入白名单：
<?php return [
'whitelist' => [
'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 源码显式引用”的包列出来——剩下的，是你的责任。
