<p>直接执行 du -sh vendor/* | sort -hr | head -20 查看占用最大的20个包；注意加 -L 参数处理符号链接，避免误判；勿依赖 installed.json 或 Packagist 下载大小估算实际体积。</p>
composer install 后怎么快速看 vendor 里谁占得最多
直接进 vendor 目录用系统命令查，别依赖 Composer 自带命令——它压根不提供包体积统计功能。composer show 只列信息，不报大小；第三方插件又容易和锁文件或平台兼容性打架。
实操建议：
- Linux/macOS 下执行：
du -sh vendor/* | sort -hr | head -20
（du统计实际磁盘占用，sort -hr按人类可读大小倒序） - Windows（WSL 或 PowerShell）：用
wsl du -sh vendor/* \| sort -hr；原生 PowerShell 较慢，不推荐用Get-ChildItem递归算 - 注意排除软链接干扰：有些包（如
symfony/flex）会建符号链接，du默认不跟随，加-L参数才准确（但会略慢）
为什么 vendor/composer/installed.json 不能用来估算包大小
这个文件只存包名、版本、安装路径和 autoload 信息，没有任何体积字段。有人想写脚本去遍历 installed.json 里的路径再 du，逻辑没错，但没必要绕一圈——直接扫 vendor/ 子目录更稳。
常见错误现象：
- 把
dist.zip下载体积当安装后体积（解压 + 生成 autoload + 缓存后通常大 2–5 倍） - 误读 Packagist 页面的 “Download size”（那是压缩包，不含
tests/、docs/，且很多包没填） - 用
composer outdated --direct混淆“是否过时”和“是否臃肿”
哪些包最容易悄悄吃掉几百 MB
不是代码多的包一定大，而是带二进制、静态资源或测试数据的包最危险。典型例子：
-
phpunit/phpunit：v9+ 含完整phpunit.phar和大量 fixture 数据，单个包常超 80MB -
laravel/framework：本身不大，但依赖的symfony/console、symfony/http-kernel等带大量注释和示例配置，叠加后膨胀明显 -
doctrine/dbal+doctrine/orm：含 SQL Server/Oracle 驱动模板、XML Schema 文件，非生产环境其实用不到 - 开发依赖如
mockery/mockery、phpspec/prophecy，测试时才需要，上线前应确保在require-dev且已--no-dev
如何避免 vendor 越滚越大
根本不是删文件，而是从安装源头控制。Composer 本身不清理历史残留，靠人工或脚本易出错。
实操建议：
- 上线部署永远加
--no-dev --optimize-autoloader，能砍掉 30%+ 体积（尤其去掉autoload-dev和未优化的 PSR-4 映射） - 定期运行
composer remove <package>而不是手动删目录，否则installed.json和 autoloader 不同步，下次install可能报错 - 警惕
"minimum-stability": "dev"：dev 分支包常含调试工具、日志 dump、未压缩资源，体积不可控 - 如果项目长期不用某 SDK（比如旧版
aws/aws-sdk-php），别留着“以防万一”，删干净再composer dump-autoload
真正麻烦的是嵌套依赖——某个你没直接 require 的包，通过三级依赖带进来了大体积子包。这时候得看 composer depends <package> 定位源头，而不是盯着 vendor 文件夹硬猜。
