Composer如何统计项目中不用的依赖包_利用分析工具精简代码【瘦身指南】

首页

编程语言

热心网友

转载

2026-05-03

Composer如何统计项目中不用的依赖包_利用分析工具精简代码【瘦身指南】

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

composer-unused 能准确识别未使用的包吗

答案是：不能完全准确，但它确实是目前最实用的静态分析工具。它的工作原理并不复杂：扫描项目里 src/ 和 tests/ 目录下的 PHP 文件，找出所有的 use 语句、new 实例化、以及 static::、self::、parent:: 这类调用。然后，拿这个结果去和 composer.json 里白纸黑字列出的 require 和 require-dev 依赖清单做比对，最后标记出那些“疑似未使用”的包。

这里有个关键点需要注意：它只做静态扫描，不执行任何代码。这意味着，所有运行时动态加载的类，它都看不见。所以，下面这几种典型情况，很容易被它误判为“未使用”：

在 config/packages/* 或 services.yaml 这类配置文件里引用的包（比如很多 Symfony 的 Bundle）。
只在注解（像 @ORM\Entity）、PHPDoc（@var Some\Class）或者测试断言里出现的类名。
通过依赖注入容器动态获取、没有显式写 use 的依赖（例如 Lara vel 里常见的 app(SomeService::class)）。

如何运行 composer-unused 并过滤误报

先用起来。推荐全局安装，方便在各个项目里使用：

composer global require composer-unused/composer-unused

安装好后，进入你的项目根目录，执行：

composer-unused --no-progress --json

加上 --json 参数，输出结果是结构化的 JSON 格式，方便你用脚本做后续处理。如果想看得更仔细，可以加上 --verbose 参数，它会告诉你每个包被哪些文件“触发”过，这能帮你判断这个包到底是不是真的没用。

面对可能的误报，别担心，它有灵活的过滤选项：

只想清理生产依赖？加 --exclude-dev 跳过开发依赖。
有些包你明知有用但被误报了？用 --ignore=vendor-name/package-name 忽略它，比如 --ignore=phpunit/phpunit。
担心扫描测试目录干扰判断？用 --path=src 把扫描范围限制在源码目录。
被注解里的类名干扰了？试试 --ignore-annotations 参数，它会跳过 @ 开头的类引用。

composer show --unused 是 Composer 内置命令吗

不是。这里有个常见的误解。即便到了 Composer 2.5 版本，官方也依然没有提供类似 composer show --unused 这样的内置功能。标准的 composer show 命令，只能老老实实地列出已安装的包及其版本，它根本不关心你的代码到底引用了谁。

所有关于“检测未使用依赖”的能力，目前都来自第三方工具。主流的选择其实就两个：

composer-unused：我们正在讨论的这个，专注静态扫描，配置灵活，目标直接。
deptrac：这个工具更侧重于架构层面的依赖关系分析，适合检查层与层之间的依赖是否违规，但对于“判断一个包是否该被删除”这种具体问题，反而不如前者来得直接。

可以亲自试试，在命令行里输入 composer show --unused，你大概率会看到 “Command ‘show’ is not defined.” 的错误提示——很多技术博客里的这个说法，其实是不准确的。

删掉包后为什么测试突然失败

这是最让人头疼的部分。有些包，你的代码里确实没有直接 use，但它可能是某个依赖链里不可或缺的一环。比如：

你删掉了 symfony/var-dumper，觉得用不上。但可能 phpunit 在它的 --debug 模式内部悄悄调用了它。
你删了 psr/log 接口包，但 monolog/monolog 在它的 composer.json 里声明了依赖这个接口。之前是 Composer 自动帮你装上的，一旦你手动删除，Monolog 在运行时就会抛出 Class ‘Psr\Log\LoggerInterface’ not found 的错误。
还有一种情况：删包后没有彻底清理。执行了 composer dump-autoload 但没清空缓存，导致旧的自动加载器还在试图引用已经删除的类。

安全的操作流程应该是：在删除任何一个包之前，先用 composer depends vendor/package 查一下，看有没有其他包依赖它。删除之后，立刻执行 composer install --no-dev 来模拟生产环境的依赖安装，并运行完整的测试套件。别忘了，优化自动加载映射这一步也很关键：composer dump-autoload -o。

话说回来，真正棘手的，是那些只在框架生命周期钩子、事件监听器或者深层配置文件里“隐形存在”的包。它们不会出现在任何直接的代码调用中，可一旦删除，系统就会在某个意想不到的时刻崩溃。对付这类依赖，工具就力所不及了，更多得依靠项目文档、开发经验，以及——做好心理准备——必要的试错。

来源:https://www.php.cn/faq/2321134.html

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：Composer如何快速同步生产环境包_使用--no-dev选项安装【生产规范】下一篇：Composer如何在Laravel部署时优化_Composer Laravel部署时优化方案