直接结论：需用 composer-unused 检测未使用包，它通过静态扫描 PHP 文件中的 use、调用等引用行为，比对 composer.json 的 require/require-dev 列表来识别冗余依赖。
如何用 composer-unused 检测未使用的 Composer 包
直接结论：官方 composer 命令不提供依赖使用分析能力，必须借助第三方工具。目前最稳定、适配 PHP 8+ 和现代 Composer 2/3 的方案是 composer-unused。
它通过静态扫描项目中所有 .php 文件，检查 use 语句、函数调用、类实例化等实际引用行为，再比对 composer.json 中的 require 和 require-dev 列表，标出「声明了但没被代码引用」的包。
- 安装方式：
composer global require composer-unused/composer-unused（推荐全局安装） - 运行前确保已执行
composer install，否则 autoload 信息缺失会导致误报 - 首次运行建议加
--no-progress避免输出干扰，例如：composer-unused --no-progress - 它默认跳过测试文件（
*Test.php）、vendor/、node_modules/等目录，如需包含测试中的使用，加--include-tests
为什么 vendor/bin/phpstan 或 php-cs-fixer 不能替代依赖检测
这类工具专注代码质量或风格，不解析依赖图谱。比如 phpstan 可能报 Class X not found，但这只说明类未加载——可能因拼写错误、命名空间错位、或 autoloader 配置问题，而非该包“未被使用”；而 php-cs-fixer 根本不关心依赖关系。
真正容易混淆的是：某个包只在 require-dev 中，但你的代码里根本没写任何调用，却因 CI 脚本或 IDE 插件间接触发了自动加载（比如某些插件会 class_exists() 探测），此时 composer-unused 仍会标记为未使用——这是正确行为，因为项目源码层确实没引用它。
-
composer-unused不分析运行时行为，只看源码显式引用 - 它不会把
phpunit这类仅在phpunit.xml或 CI 脚本中出现的工具判为“已使用” - 若某包仅被
config/packages/*.yaml（Symfony）或services.php引用，且无 PHP 类调用，也会被识别为未使用——这属于框架配置驱动场景，需人工确认
排除误报：如何告诉 composer-unused “这个包我确实在用”
常见误报集中在三类情况：运行时动态加载（class_alias、call_user_func）、注解驱动（Doctrine、PHPStan 扩展）、以及框架服务配置。这时不能删包，而是配置白名单。
在项目根目录添加 composer-unused.php 配置文件：
[
'doctrine/annotations',
'phpunit/phpunit',
'myvendor/my-runtime-extension',
],
];
- 白名单项必须与
composer show输出的包名完全一致（含 vendor 名） - 不支持通配符，
monolog/*无效；多个包逐行写全名 - 配置后需重新运行
composer-unused，否则仍会提示 - 如果包仅用于生成代码（如 Swagger 注解解析器），也应加入白名单，避免误删导致生成失败
删包前务必验证的两个动作
检测只是第一步，删除依赖有风险。尤其当包同时出现在 require 和 require-dev，或被其他已安装包的 composer.json 声明为 conflict 时，直接 composer remove 可能破坏依赖树。
- 先手动注释掉
composer.json中疑似冗余的包，再运行composer update --dry-run，观察是否出现冲突或降级提示 - 删包后，至少跑一次
composer dump-autoload -o，然后执行php -l扫描全部.php文件，确认无Parse error: syntax error类报错（说明没漏掉use） - 若项目含单元测试，必须运行
./vendor/bin/phpunit，某些包虽无直接use，但可能被测试断言逻辑隐式依赖（如特定异常类）
最常被忽略的是：有些包（如 symfony/polyfill 系列）看似没被主动引用，实则被其他组件通过 class_exists() 动态探测并启用——删掉后运行时才暴露问题。这种只能靠完整功能回归或日志监控捕获。
