唯一可靠方式是运行composer config --global cache-dir，输出即当前实际生效的缓存路径；Linux/macOS可用du -sh验证大小，Windows可将路径粘贴至资源管理器查看属性。
怎么确认 Composer 正在用哪个缓存路径
别猜，也别直接去 ~/.composer/cache 或 %APPDATA%\Composer\Cache 盲删——这两个只是默认路径，实际生效的可能被 COMPOSER_CACHE_DIR 环境变量、公司镜像配置或 config.json 覆盖。
唯一可靠的方式是运行：
composer config --global cache-dir
它输出的才是 Composer 当前写入缓存的真实绝对路径。Linux/macOS 用户可直接把结果代入 du -sh 查大小；Windows 用户把路径粘贴进资源管理器地址栏（支持 %APPDATA% 展开），右键 → “属性”看占用。
不到 200 MB 基本不用管；超 1.5 GB 且对应项目半年没动过，才值得清理。
为什么 composer clear-cache 删完空间没变
最常见原因有三个，按发生频率排序：
- 你真正想删的是
vendor/目录（中等 Laravel 项目常占 300–800 MB），而缓存本身可能只有 42 MB -
vcs/子目录默认被clear-cache跳过，但单个 Git 裸仓库就吃掉 300–800 MB，还会耗尽 inode；必须手动删：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 临时目录（
sys_get_temp_dir()）下堆积了大量composer_*.zip、php*.phar，这个位置clear-cache完全不碰
CI/CD 或无交互终端里执行 clear-cache 卡住怎么办
GitHub Actions、GitLab CI 等环境默认会等待交互确认，导致命令 hang 住。
必须加 --no-interaction：
composer clear-cache --no-interaction
更稳妥的做法是先预检：
composer clear-cache --no-interaction --dry-run
确认输出的路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘）。如果仍卡住，说明有后台进程锁着缓存目录：
- Linux/macOS：
lsof +D $(composer config --global cache-dir) - Windows：需下载 Sysinternals 的
handle.exe，运行handle.exe -p php.exe
手动删比 clear-cache 更“精准”，但也更危险
官方命令会跳过正在被占用的文件，而 rm -rf 不判断——删到一半被写入，后续可能报 Corrupted cache。
若真要手动删，请只删明确无用的部分：
-
files/：所有下载的.zip/.tar包，安全可删 -
repo/：包元数据快照，清完首次 install 会慢一点，但无风险 -
vcs/：必须删，但要用rm -rf彻底清空子目录，不能只删里头的.git文件夹
别碰 archives/（部分版本存在），也不建议删整个缓存根目录——万一有进程正往里写，容易破坏结构。
