Composer实际缓存目录应以composer diag输出的Cache directory为准，而非composer config cache-dir；其核心占用在cache/files/子目录，可用du -sh cache/files精准统计，composer show -s统计的是vendor源码体积，与缓存无关。
Composer 本身不提供直接查看缓存总大小的命令，但能快速定位缓存目录并用系统工具统计——关键不是“怎么查”，而是“查哪个目录、为什么不能只信 composer config cache-dir”。
怎么确认 Composer 实际在用的缓存目录
很多人执行 composer config cache-dir 看到路径就去 du -sh，结果发现数值不对。这是因为该命令只读配置项，不反映真实生效路径：
-
composer diag输出里的 Cache directory 行才是最终生效路径，它已综合了COMPOSER_CACHE_DIR环境变量、全局配置、默认逻辑 - 若
composer config cache-dir输出为空，不代表没缓存——Linux/macOS 默认走~/.composer/cache，Windows 默认是%LOCALAPPDATA%\Composer\cache或%APPDATA%\Composer\Cache（二者不同，diag才准） - CI/容器环境常通过
COMPOSER_CACHE_DIR=/tmp/composer-cache覆盖，此时config cache-dir可能仍显示旧值，但diag会如实输出
怎么准确统计缓存占用空间
缓存目录下有两个核心子目录：files（存下载的 zip/tar 包）和 repo（存元数据 JSON），真正占空间的是 files：
- 进真实缓存根目录后，运行：
du -sh cache/files—— 这是绝大多数空间来源 -
du -sh cache/repo通常只有几 MB，除非你长期未清理且依赖极多 - 别用
du -sh cache：里面可能有残留的archives（已弃用）、http（HTTP 缓存，极少）等干扰项 - 想看哪些包最占缓存？进
cache/files后：du -sh */*/ | sort -hr | head -5，输出类似124M vimeo/psr-http-message/...
为什么 composer show -s 查不到缓存大小
composer show -s 统计的是 vendor/ 下已安装包的源码目录大小，和缓存完全无关：
- 它不读
cache/files，也不解压 zip，只是du -sh当前项目vendor目录 - 一个包可能在缓存里存了 5 个版本（5 个 hash 文件夹），但
show -s只显示当前装的那个版本的源码体积 - 缓存里存的是压缩包（.zip/.tar），而
show -s是解压后的代码+测试+文档，二者单位、内容、用途都不同
手动删缓存前必须注意的权限陷阱
尤其在 Docker、CI 或 NFS 挂载场景下，删完发现下次 install 还是重下——大概率是缓存目录权限失效：
- Composer 写缓存失败时静默跳过，不会报错，只退化为无缓存模式
- 检查
cache/files目录是否可写：touch cache/files/test && rm cache/files/test - Docker 构建中挂载宿主机缓存目录时，确保容器内 UID/GID 与宿主机一致，否则写入失败
- 用
composer clear-cache清理后，立刻执行composer require monolog/monolog并观察是否生成新 hash 目录，才能验证缓存是否真启用
缓存大小本身不重要，重要的是确认它被真实使用且路径可控；composer diag 和 du -sh cache/files 组合，比任何第三方插件都可靠。
