composer config --global cache-dir 输出的是 Composer 当前实际生效的全局缓存根目录，即 clear-cache 清理位置及 files/、repo/、vcs/ 子目录的实际落盘路径，优先级上环境变量 COMPOSER_CACHE_DIR 高于配置，未设置时取系统默认路径。
composer config --global cache-dir 查的是哪个路径
它输出的就是 Composer 当前认的全局缓存根目录，不是猜测值，也不是默认值——是实际生效路径。Linux/macOS 下通常是 ~/.composer/cache，Windows 下是 %APPDATA%\Composer\Cache。如果你设过 COMPOSER_CACHE_DIR 环境变量，这里显示的就是那个自定义路径；没设就走系统默认。这个路径决定了 composer clear-cache 到底清哪儿，也决定了所有缓存文件（files/、repo/、vcs/）的实际落盘位置。
为什么 du -sh $(composer config --global cache-dir) 有时显示 0B
常见原因有三个：
-
cache-dir指向的目录确实不存在，比如第一次用 Composer 还没触发过下载，或者被手动删空后没重建子目录 - 权限问题：当前用户对目录无读取权，
du跳过统计，返回 0B（Linux/macOS 常见于之前用sudo composer install写入，现在普通用户执行） - 路径里含空格或特殊字符，
$(...)展开失败，du实际执行的是du -sh（无参数），结果为 0B
验证方法：先 ls -la $(composer config --global cache-dir)，看是否报 No such file or directory 或 Permission denied。
files/、repo/、vcs/ 这三个子目录分别存什么
它们分工明确，删错会影响不同行为：
-
files/：所有已下载的.zip、.tar包原始归档，按 vendor/name/version-hash 命名。删它 = 下次install必须重下压缩包，尤其影响含大前端资源的包（如laravel/ui） -
repo/：远程源的元数据快照，比如packagist.org/packages.json及其子集（搜索结果、版本列表）。删它 = 下次update或首次install得重新 HTTP 请求拉全量索引，明显卡顿 -
vcs/：Git 仓库的浅克隆（bare clone），用于从 Git URL 安装包时复用。删它 = 下次装 vcs 类包（如"monolog/monolog": "dev-main#abc123"）要重新git clone --depth=1，但不影响 dist 包安装
注意：archives/ 和 downloads/ 是旧版 Composer 使用的目录名，2.x+ 已统一为 files/；如果看到这两个目录，说明你用的是非常老的 Composer 版本。
CI/CD 中缓存路径可能不只一个
很多团队在 CI 流水线里会挂载共享缓存卷（如 Docker volume、NFS），并用 COMPOSER_CACHE_DIR 指向它。这时候 composer clear-cache 默认只清这个环境变量指向的路径，不会自动扫描其他可能存在的缓存位置。容易忽略的点是：
- 某些构建镜像自带预填充的
/tmp/composer-cache，但没配COMPOSER_CACHE_DIR，结果clear-cache根本没清到那里 - 多阶段构建中，build 阶段和 final 阶段用不同用户运行 Composer，缓存目录权限错乱，
clear-cache在 final 阶段静默失败 - 企业私有镜像（如腾讯云 TKE Composer 镜像）会在响应头加
X-Composer-Cache-TTL，本地清了没用，得等镜像源自己刷新
真正要确认清干净，得进对应路径手工 ls -l，别只信命令输出的 “All caches cleared.”。
