答案是缓存路径可能被COMPOSER_CACHE_DIR或镜像覆盖，需先用composer config --global cache-dir确认真实路径，再用du -sh（Linux/macOS）或资源管理器属性（Windows）查占用；超1.5GB且半年未用才值得清理，重点清cache/files/旧ZIP、cache/vcs/裸仓库及sys_get_temp_dir()下临时文件。
Composer 缓存本身不占多少空间，真正吃掉磁盘和 inodes 的是 cache/files/ 里的 ZIP 包、cache/vcs/ 里的 Git 裸仓库，还有 sys_get_temp_dir() 下堆积的临时解压文件——别清“镜像”，清这些才管用。
怎么确认缓存路径和真实占用？别删错地方
很多人一看到磁盘告警就跑 composer clear-cache，结果空间没变——因为缓存路径可能早被 COMPOSER_CACHE_DIR 或公司镜像覆盖，~/.composer/cache 根本不是 Composer 当前用的目录。
- 先查真实路径：
composer config --global cache-dir - Linux/macOS 看大小：
du -sh $(composer config --global cache-dir) - Windows 直接在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache→ 右键“属性” - 不到 200 MB？基本不用管；超过 1.5 GB 且半年没碰老项目，才值得动手
cache/vcs/ 是 inode 杀手，clear-cache 默认不管它
~/.composer/cache/vcs/ 存的是完整 Git 裸仓库（含 .git），单个包克隆就吃掉 300–800 MB，文件数动辄上万。它不参与 composer clear-cache 流程，却是 No space left on device 的高频元凶——尤其当 df -i 显示 inode Use% 接近 100% 时。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 禁用它最省事：
composer config --global cache.vcs false，之后所有包强制走--prefer-dist - 已存在的可安全手动删：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 注意：禁用后首次
composer update会慢一点（重下 dist 包），但后续更稳，且不再偷偷耗尽 inodes
sys_get_temp_dir() 才是真·隐形炸弹
Composer 解压 ZIP、生成 autoload、执行脚本时重度依赖 PHP 的 sys_get_temp_dir() 返回路径。Windows 默认是 C:\Users\用户名\AppData\Local\Temp，Linux/macOS 是 /tmp——这里堆积的 composer_*.zip、php*.phar 文件往往比缓存还难察觉。
- 先查真实路径：
php -r "echo sys_get_temp_dir();" - Windows 用户直接进资源管理器搜
composer_* - Linux/macOS 运行：
find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -delete 2>/dev/null - 长期方案：用环境变量重定向，比如 Linux 上启动时加
TMPDIR="/mnt/data/tmp" php composer install，避免污染系统级/tmp
换 cache-dir 比反复 clear-cache 更治本
默认缓存路径常落在小容量分区（如 Windows 的 C 盘 %APPDATA% 或 Linux 的 /home 分区），清完一周又满。
- 把缓存迁到大容量盘：
composer config --global cache-dir "/mnt/data/composer-cache" - 别直接
rm -rf files/——多个项目共用同一 ZIP 是常态，删错会导致下次composer install重复下载 - 想精准瘦身：进
files/子目录，按修改时间排序，手动删掉 90 天前的子目录，比如：find ~/.composer/cache/files -type d -mtime +90 -delete
真正容易被忽略的是：某些团队把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 composer config --global cache-dir 指向的那个路径，不会遍历所有可能位置。
