Composer 不提供原生未使用依赖检测，需借助 composer-unused 等第三方工具结合静态分析与人工验证；因 PHP 动态特性（如反射、字符串类名、DI 注入），自动识别不可靠，移除前须多维度确认。
Composer 本身不提供原生的“未使用依赖”检测功能，
只能按手动指定包名卸载，无法自动识别哪些包在代码中实际没被引用。真要查未使用依赖，得靠第三方工具辅助，且必须结合静态分析和项目上下文判断。
为什么
不存在
很多人误以为 Composer 内置类似 npm 的
或
功能，但官方从未实现依赖使用率分析——因为 PHP 没有统一的 import 语法（支持
、
、
、反射、字符串类名、DI 容器动态加载等），静态扫描天然不可靠。
和
只管理
目录与
映射，不跟踪运行时调用
即使某个包没被任何
或
引用，它仍可能被插件系统、配置文件或测试代码间接依赖
移除前必须确认：该包是否仅用于开发（
）、是否被
加载、是否被 PHPUnit 或 Behat 等工具链依赖
推荐工具：
+
是目前最贴近需求的 CLI 工具，底层基于
做符号解析，能扫描
和
下的类引用，跳过注释和字符串中的假阳性匹配。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
安装：
基础扫描：
（默认只检查
中的包）
检查
：
忽略特定包（如 Laravel 的 facade 别名）：
注意：它不会扫描
或
中的字符串类名，这类需人工核对
常见误报和必须人工验证的场景
工具报告“未使用”，不等于可以安全删除。以下情况几乎必然误报：
Laravel 的服务提供者（
中
动态注册）
Symfony Bundle 类（
中启用但无直接 PHP 引用）
Doctrine 扩展（通过
注解隐式依赖）
PSR 接口实现（如
在 DI 配置中注入，代码里只类型提示不 new）
PHP 扩展级依赖（如
不在
，但包声明了
）
真正安全移除的信号是：工具未报错 +
无结果 +
返回空 + 确认 CI 流水线仍通过。别跳过最后一步。
composer removecomposer show --unusednpm ls --depth=0depcheckrequireincludeclass_aliascomposer installcomposer updatevendor/autoloadusenewrequire-devautoload-devroave/better-reflectioncomposer-unusedcomposer-unusedroave/better-reflectionsrc/tests/composer require --dev composer-unused/composer-unused./vendor/bin/composer-unusedrequirerequire-dev./vendor/bin/composer-unused --dev--exclude "illuminate/support"config/*.phproutes/*.phpAppServiceProvider$this->app->register(...)bundles.php@ORMSomething PsrLogLoggerInterface ext-memcachedcomposer.json"ext-memcached": "*"grep -r 'Vendor\Package' src/ tests/ --include='*.php'composer depends vendor/package