直接运行composer clear-cache仅清理files/和repo/，不清理vcs/和系统临时目录的composer_*.zip文件；需用composer config --global cache-dir确认真实路径，再针对性清理三处高占用位置并禁用cache.vcs治本。
直接运行 composer clear-cache 通常只能释放几十到几百 MB，真正吃空间、耗 inode 的是 vcs/ 目录和系统临时目录里的 composer_*.zip 文件——不碰这两处，磁盘和 inode 很可能还是满的。
怎么确认 Composer 正在用哪个缓存路径？
很多人删了 ~/.composer/cache 却没效果，是因为缓存路径早被环境变量或公司镜像改过了。必须查真实路径：
- 运行
composer config --global cache-dir，输出才是当前生效的路径 - Linux/macOS 查大小：
du -sh $(composer config --global cache-dir) - Windows 直接在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache→ 右键“属性” - 不到 200 MB 基本不用管；超 1.5 GB 且半年没动老项目，才值得清理
为什么 composer clear-cache 清完空间没变？
最常见原因有三个，按实际发生频率排序：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 你真正想删的是
vendor/（一个中等 Laravel 项目常占 300–800 MB），而clear-cache完全不碰它 -
cache/vcs/默认被跳过——单个 Git 裸仓库含完整.git，动辄 300–800 MB，还生成上万小文件，是No space left on device的高频元凶 -
sys_get_temp_dir()下堆积的composer_*.zip、php*.phar文件没被清理，这个路径 Windows 是%TEMP%，Linux/macOS 是/tmp
手动清理三处最占空间的位置
先停掉所有 composer 进程（ps aux | grep composer 或 tasklist | findstr composer），否则删一半会报 Corrupted cache file：
- Linux/macOS：
rm -rf $(composer config --global cache-dir)/vcs - Windows：
rd /s /q "%APPDATA%\Composer\Cache\vcs" -
cache/files/（ZIP 包）：可按时间删旧包，例如 Linux/macOS：find $(composer config --global cache-dir)/files -type d -mtime +90 -delete - 临时目录：
php -r "echo sys_get_temp_dir();"查路径，再删匹配文件，例如 Linux/macOS：find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -mmin +60 -delete 2>/dev/null
长期避免反复爆满的关键动作
反复清理只是擦边球，治本靠配置：
- 禁用 Git 缓存：
composer config --global cache.vcs false，后续所有包强制走--prefer-dist - 换缓存路径到大分区：
composer config --global cache-dir "/mnt/data/composer-cache"（注意：路径必须是绝对路径，不能含~，且需提前mkdir并赋权） - 设缓存上限（Composer 2.5+）：
composer config --global cache-max-size "500M"
真正容易被忽略的是 vcs/ 目录里那些 Git 仓库副本——它们不常复用，却持续占用大量空间和 inode，且 clear-cache 默认完全跳过。清之前务必确认无后台进程占用，否则重建缓存时可能出错。
