Composer如何查看每个依赖的大小_分析项目体积占用情况【优化笔记】

开门见山，先说一个核心事实：Composer本身并不提供依赖体积分析功能。这意味着，单纯依靠composer install或composer update，你无法直接获取每个包到底占了多少磁盘空间。它的核心任务是解决依赖关系和安装包，至于扫描文件系统、计算磁盘占用这些活儿，它一概不管。所以，无论是composer show查看包信息，还是借助composer-unused这类插件，都只能接触到版本、描述这些元数据，跟实际的文件大小完全不沾边。

Composer 本身不提供依赖体积分析功能

直接运行 composer install 或 composer update 不会输出任何包大小信息。Composer 的职责是依赖解析与安装，它不扫描文件系统、不计算磁盘占用，也不缓存或暴露每个包的体积数据。想靠 composer show、composer outdated 或插件机制（如 composer-unused）查体积，都会失败——这些命令只处理元数据（版本、描述、require 列表），和实际文件大小无关。

用 du + composer show --installed --no-ansi 快速估算 vendor 下各包体积

那么，有没有轻量级、无需额外工具的方法？当然有。最直接的思路就是：先拿到已安装包的名单，然后逐个去vendor/目录下“称重”。这里有个细节必须注意，路径必须严格匹配。比如包monolog/monolog，对应的目录是vendor/monolog/monolog，可别错看成vendor/monolog。

在Linux或macOS环境下，可以执行下面这条组合命令：

composer show --installed --no-ansi | grep -E '^[a-z0-9\-]+/[a-z0-9\-]+' | cut -d' ' -f1 | while read pkg; do echo "$(du -sh vendor/$pkg 2>/dev/null | cut -f1)  $pkg"; done | sort -hr | head -20

这条命令干了这么几件事：

• 先用composer show --installed --no-ansi拉出纯净的包列表，避免颜色代码干扰解析。
• 接着用grep过滤出标准格式的包名，把空行、扩展名这些杂项踢出去。
• 然后循环遍历每个包，用du -sh去计算对应目录的大小，2>/dev/null是为了屏蔽掉一些无伤大雅的权限或链接错误。
• 最后，按人类可读的格式从大到小排序，并只展示前20个“大块头”。

警惕 vendor/bin、tests、docs 等非运行时目录带来的虚高

拿到初步数据先别急着下结论，这里有个常见的“坑”。很多包，比如phpunit/phpunit或者symfony/console，会把测试用例、文档、甚至二进制脚本全都打包进发行版里。这些东西在生产环境里根本用不上，但如果你直接用du -sh vendor/xxx去统计，就会严重高估这个包的“真实体重”。

所以，我们需要更精细地排查：

• 首先，检查是否已经启用了Composer的--no-dev和--optimize-autoloader选项。它们虽然不会减少vendor/目录的物理大小，但能显著降低运行时的加载开销。
• 用composer install --no-dev重新安装后，再跑一遍上面的du命令，这样就能彻底排除开发依赖包的干扰。
• 对于体积特别可疑的包，不妨直接进入其目录，运行du -sh */ | sort -hr看看子目录的分布。如果发现tests/、docs/、examples/占了大部分空间，那心里就有数了。
• 安装时使用--prefer-dist --no-scripts选项也是个好习惯，能避免下载源码包，并跳过可能生成额外缓存或产物的安装后脚本。

真正要优化体积？别只盯着单个包，重点看 autoloader 和 classmap

话说回来，单纯比较哪个包占的磁盘空间大，有时候会把人带偏。PHP应用启动慢、内存占用高，真正的瓶颈往往不在某个巨大的“单体包”上，而在于自动加载机制。想象一下，一个5MB的包，如果里面塞了2000个零碎的小PHP文件，那它对性能的拖累，可能远超一个15MB但只有50个类的、结构清晰的包。

因此，优化体积的战场，应该转移到自动加载和依赖结构上：

• 运行composer dump-autoload --optimize --classmap-authoritative。这能强制生成一个完整的类映射表，让Composer在运行时直接按图索骥，而不是去遍历那些psr-4目录，效率提升立竿见影。
• 检查你的composer.json，autoload配置是否还停留在psr-0？或者命名空间前缀设置得过于宽泛？这都会导致Composer扫描的范围过大。
• 用composer show --tree看看依赖树的深度。过深的嵌套可能引入重复或已被废弃的包，比如两个组件各自依赖了不同版本的guzzlehttp/promises。
• 市场上有不少包提供了“精简版”，例如ramsey/uuid-doctrine就是为减少依赖而设计的。在替换前，务必确认功能覆盖是否完整。

总而言之，用du命令分析包大小，只是一个起点。真正的性能卡点，常常隐藏在自动加载的行为模式和复杂的依赖拓扑关系里。别让目录大小数字，模糊了优化真正的方向。