直接运行composer clear-cache可安全清理macOS上Composer全局缓存，但它仅删除~/.composer/cache/下的files/、repo/、installers/子目录，默认跳过占空间最大的vcs/目录；真实路径需用composer config --global cache-dir确认，大小用du -sh检查，超1.5 GB且半年未用才建议清理；vcs/须手动删（rm -rf ~/.composer/cache/vcs/）或禁用（composer config --global cache-vcs false）；CI环境需加--no-interaction防卡住。
直接运行 composer clear-cache 就能清掉 macOS 上的 Composer 缓存，但它只动 ~/.composer/cache/ 下的 files/、repo/、installers/，默认跳过真正占空间的 vcs/ —— 这是多数人清完发现磁盘没变化的根源。
确认真实缓存路径和大小再动手
别信“应该在 ~/.composer/cache”这种经验判断。Composer 实际路径可能被 COMPOSER_CACHE_DIR 环境变量或公司镜像覆盖。
- 查真实路径：
composer config --global cache-dir - 看真实体积：
du -sh $(composer config --global cache-dir) - 不到 200 MB 基本不用管；超 1.5 GB 且半年没碰老项目，才值得清理
为什么 clear-cache 后磁盘空间没变？
常见原因不是命令失效，而是它根本没删到大头：
-
vcs/目录默认被跳过，但一个 Laravel 的 Git 克隆缓存就占 300–800 MB，还耗尽 inode - 临时目录
sys_get_temp_dir()（通常是/tmp）里堆积了大量composer_*.zip、php*.phar，clear-cache完全不碰这里 - 你以为占空间的是缓存，其实真凶是
vendor/—— 它不属于 Composer 缓存体系，删了项目直接崩
精准释放：清完立刻补一刀 vcs/
composer clear-cache 执行完，立刻手动删 vcs/ 才算真正见效：
- 安全命令：
rm -rf ~/.composer/cache/vcs/（注意末尾斜杠，避免误删上层） - 删之前先确认：
ls -ld ~/.composer/cache/vcs/看是否存在、是否可写 - 如果想一劳永逸，禁用 Git 缓存：
composer config --global cache-vcs false，后续所有包强制走--prefer-dist
CI 或无交互环境卡住怎么办？
GitHub Actions、GitLab CI 里 composer clear-cache 默认会等交互确认，直接 hang 住：
- 必须加
--no-interaction：composer clear-cache --no-interaction - 建议先
--dry-run预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 仍卡住？说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)查占用进程
最常被忽略的点：vcs/ 不清，缓存清理就等于只擦了玻璃一角；而 /tmp 空间不足时，哪怕缓存清得干干净净，composer install 依然会在解压阶段报 No space left on device。
