du命令统计vendor目录空间最准确，需配合--apparent-size、-l、--no-dev等参数规避硬链接、符号链接及开发依赖干扰，windows用户须用wsl或git bash；切勿依赖disk_total_space等函数或误提交vendor至git。
du 命令直接看 vendor 占用空间最准
别依赖 Composer 自带命令，它根本不提供目录体积统计功能。du 是唯一靠谱、无依赖、秒出结果的方案。Windows 用户请先装 WSL 或 Git Bash，原生 cmd/powershell 没法准确算符号链接和嵌套深度。
常见错误现象：du -sh vendor 返回值偏小——因为默认不进子目录（尤其 vendor/composer/installed.json 被大量包引用，但 du 默认跳过硬链接重复计数）；或者返回值异常大——没排除 node_modules 或 .git 等混入内容。
-
du -sh vendor/：粗略总览，适合快速判断是否“明显膨胀” -
du -sh vendor/* | sort -hr | head -n 10：查出前 10 大包，定位“谁吃掉了空间” -
du -sh --apparent-size vendor/*：加--apparent-size避开硬链接干扰，更贴近实际磁盘占用感知
排除 dev-dependencies 后再统计才反映生产环境真实体积
很多项目把测试工具（如 phpunit、infection）、代码生成器（如 laravel/pint）全装进 vendor，但它们在部署时根本不用。光看总量会误判部署包大小。
使用场景：CI 流水线做容量监控、Docker 构建层优化、SaaS 多租户资源配额核算。
- 先执行
composer install --no-dev清掉开发依赖，再跑du，这才是上线镜像该有的体积 - 若项目用了
config.platform模拟低版本 PHP，记得加--ignore-platform-reqs再装一次，否则du统计的是“本地能跑”的体积，不是“目标环境能跑”的体积 - 注意
vendor/bin下的二进制文件可能被 symlink 到全局，du默认不追踪，得加-L参数才计入（但通常不建议——它们本就不该算进项目体积）
PHP 脚本调用 disk_total_space 和 disk_free_space 不适用
这两个函数返回的是整个文件系统信息，不是 vendor 目录本身大小。有人误以为传入 vendor 路径就能得到子目录用量，其实只是返回根分区剩余空间——完全跑偏。
性能影响：函数调用快，但数据毫无意义；兼容性上，Windows 下行为更不稳定（NTFS 簇大小、压缩属性会影响结果）。
- 别写
disk_usage('vendor')这种封装函数，底层没这能力 - 真要用 PHP 统计，老实用
exec('du -sb vendor 2>/dev/null', $out)解析第一行数字，再除以 1024/1024 得 MB - 注意
exec在 Docker 容器或禁用函数环境中可能被关掉，不如直接 shell 脚本可靠
Git 仓库里 vendor 提交了？du 结果会包含 .git/object 的冗余体积
如果误把 vendor 提交进 Git（哪怕只是一次），.git/objects 里存了所有历史版本的包文件快照，du -sh vendor 看不到，但 du -sh .git 会暴增。这时候你盯着 vendor 优化是白忙。
容易踩的坑：CI 日志显示 “vendor size: 120MB”，但构建机器磁盘告警，一查 .git 占了 800MB——因为某次调试手动 git add vendor 了。
- 运行
git ls-files vendor/ | head -n 5，只要输出非空，立刻git rm -r --cached vendor并提交 .gitignore 补漏 -
du -sh .git/objects/pack能快速确认是否被 pack 文件塞爆 - 用
git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -n 5找出最大的五个对象，再git show <hash> | head -c 100</hash>看是不是 vendor 里的某个 phar
真正卡住人的是“你以为在量 vendor，其实量的是 git 历史”或者“你按本地 dev 环境量，却要为 production 镜像背锅”。盯紧 --no-dev 和 .gitignore 这两处，比任何自动化脚本都管用。
