<p>最直接查看已安装包清单用 composer show -i，但需结合 du -sh vendor/* | sort -hr 查真实大小，再用 composer why-not 定位依赖阻止删除的原因。</p>
composer show -i 查看已安装包清单
这是最直接的起点，composer show -i 会列出所有已安装的包及其版本，但不带大小信息。它本身不解决“谁占空间大”的问题，但能帮你确认哪些包确实被装进来了——尤其当你怀疑某些 dev-only 包（比如 phpunit、larastan）意外进了生产环境时，先扫一眼很必要。
注意：这个命令输出是按字母序排的，不是按体积。别指望靠它一眼看出 symfony/symfony 和 doctrine/orm 谁更吃磁盘。
du -sh vendor/\* | sort -hr 查看各包目录真实大小
Linux/macOS 下真正管用的是系统命令组合：du -sh vendor/\* 统计每个子目录占用，sort -hr 按人类可读格式倒序排列。结果里排在最上面的几个 vendor/symfony、vendor/nikic/php-parser、vendor/composer 就是你该盯住的重点。
常见错误现象：
• 忘了加 \* 导致只统计 vendor 目录本身（通常是空的或极小）
• 在 Windows PowerShell 里直接运行会报错，得换用 WSL 或 Git Bash
• vendor/composer 看起来很大？别慌，它主要是 installed.json 和类映射缓存，实际可安全忽略
- 如果项目用了
composer install --no-dev，但du结果里仍有大量测试相关包（如phpunit/phpunit），说明require-dev没生效或被覆盖了 -
vendor/bin通常很小，但某些包（如phpstan）会把完整 PHAR 扔进去，值得单独du -sh vendor/bin/*看一眼
composer why-not xxx 弄清包为何没被删掉
你删过某个大包（比如 ramsey/uuid），composer remove ramsey/uuid 却失败，提示 “is required by”，这时候 composer why-not ramsey/uuid 能告诉你具体哪个包在依赖它——可能是你没意识到的间接依赖，比如 laravel/framework → illuminate/support → ramsey/uuid。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
这个命令不显示大小，但它解释了“为什么你删不掉那个占地方的包”。很多开发者卡在这一步，反复删包失败，其实只是没看清依赖链。
- 输出里出现
root，代表你自己在composer.json的require或require-dev里写了它 - 如果某包被多个路径引用，
composer why-not只显示一条路径；想看全，得手动查composer show --tree xxx - 别信 IDE 自动补全的“移除未使用依赖”提示，它不考虑运行时反射、配置驱动加载等真实依赖场景
vendor/composer/installed.json 里没有大小字段
有人想从 Composer 自身元数据里扒出体积信息，打开 vendor/composer/installed.json 会发现只有 name、version、type、autoload 等字段，压根没有 size 字段。Composer 不记录也不计算包大小，这是有意为之的设计：它只管依赖解析和文件安装，磁盘占用是操作系统的事。
所以任何试图靠改写 composer.json 或 hook Composer event 来“自动清理大包”的方案，都会绕远路。老老实实用 du + composer why-not 组合，快且准。
容易被忽略的一点：.git 目录可能藏在 vendor 子包里（尤其是你 fork 并本地 require 的包），这种包的 du 结果会虚高——记得顺手 find vendor -name ".git" -type d | head -5 扫一遍。
