Composer 本身不提供原生命令检测未使用依赖，因遵循声明式依赖管理哲学，不分析代码调用；推荐使用 roave/composer-dependency-analyser 进行 AST 静态分析。
Composer 本身不提供原生命令检测未使用的依赖包，必须借助第三方工具；直接运行 composer unused 或类似命令会报错——它不是 Composer 内置功能。
为什么 composer show --unused 不存在
Composer 的设计哲学是“声明式依赖管理”，只负责安装、更新和解析 composer.json 中显式声明的包，不分析代码实际调用情况。因此：
• 它不会扫描 .php 文件里的 use、new 或 class_exists
• 不跟踪运行时动态加载（如 class_alias、require_once 路径拼接）
• 无法识别测试专用依赖（如 phpunit 在 require-dev 中但未被任何 *Test.php 引用）
推荐工具：roave/composer-dependency-analyser
目前最稳定、维护活跃、支持 PHP 8+ 的静态分析方案。它通过 AST 解析项目全部 PHP 文件，比正则更可靠，且能区分 require 和 require-dev。
- 安装：
composer require --dev roave/composer-dependency-analyser
- 首次运行（生成 baseline，避免误报历史冗余）：
vendor/bin/dependency-analyser --generate-baseline
- 日常检查：
vendor/bin/dependency-analyser
- 关键行为：
- 仅报告在
composer.json中声明、但在源码中**零引用**的包 - 跳过
autoload-dev下的文件（除非你手动加--include-dev） - 默认忽略
psr-4映射外的类（如tests/目录需显式配置）
- 仅报告在
其他可选工具及注意事项
deptrac 和 phpstan-deprecation-rules 不适用于此场景——它们专注层依赖或弃用检测，非“未使用”判断。
-
composer-unused（v0.12+）：轻量，但对 trait 使用、动态类名、PHP 8.2 枚举常量引用支持不稳定，容易漏报
• 运行前需确保vendor/autoload.php可正常加载（否则报Class not found） - 自建脚本风险高：用
grep -r "new Foo" .类似方式会漏掉接口实现、注解、配置数组键名等间接引用 - CI 中建议加
--fail-on-unused（roave支持），但上线前务必人工确认——比如某包只在 Dockerfile 中用于构建，代码里确实没调用，这时不应删除
真正难的不是发现冗余，而是判断“这个包到底算不算被使用”：它可能藏在配置文件里、被某段条件编译代码包裹、或只在特定扩展启用时才生效。工具只能给出线索，删之前得看上下文。
