composer clear-cache 默认不清理最占空间的 vcs/ 目录，需手动删除；先用 composer config --global cache-dir 确认真实路径，再用 du -sh 或资源管理器查看占用，超 1.5 GB 且半年未用才值得清理。
直接运行 composer clear-cache 通常不能释放你真正关心的磁盘空间——它默认跳过最占地方的 vcs/ 目录，而这个目录单个 Git 裸仓库就能吃掉 300–800 MB。
怎么确认缓存路径和真实占用？别删错地方
很多人一看到磁盘告警就跑 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 且半年没碰老项目，才值得动手
为什么 composer clear-cache 清完空间没变化？
最常见原因是你想删的是 vendor/，不是缓存。一个中等 Laravel 项目 vendor/ 常占 300–800 MB，而缓存可能只有 42 MB——清它当然没用。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer clear-cache默认只清files/、repo/、http/，**跳过vcs/** -
vcs/存的是完整 Git 裸仓库（含.git），切分支/换源频繁时极易积攒废弃仓库，几乎不复用 - 要清它，得手动：
rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 清完再跑
du -sh $(composer config --global cache-dir)，才能看到真实释放量
CI/CD 或无交互终端里卡住？加这两个参数
在 GitHub Actions、GitLab CI 里，composer clear-cache 默认会等交互确认，直接 hang 住。
- 必须加
--no-interaction：避免卡在提示 - 建议加
--dry-run先预检：输出将清理的路径，确认是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 命令组合示例：
composer clear-cache --no-interaction --dry-run→ 确认无误后再去掉--dry-run - 如果仍卡住，说明有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或handle.exe -p php.exe（Windows，需 Sysinternals 工具）
想省空间又不想全删？手动进目录精准清理
composer clear-cache 是全量操作，没有按包名、时间、大小筛选的内置选项。所谓“精准”，只能靠你自己判断子目录用途：
-
~/.composer/cache/files/：存所有.zip/.tar包，冗余最多。可用find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete清 90 天前的老包 -
~/.composer/cache/vcs/：存 Git 浅克隆，安全删：rm -rf ~/.composer/cache/vcs/*，下次需要自动重建 -
~/.composer/cache/repo/packagist.org/：这是核心索引缓存，删了会导致首次composer update明显变慢，不建议动 - 手删前务必确认没有
composer install或update进程在后台运行，否则可能触发Corrupted cache file报错
真正容易被忽略的是：vcs/ 目录长期滞留、几乎不复用，但它才是磁盘和 inode 的隐形杀手；而手动删它之前，没人检查是否真有进程在占用——一删就报错，还得回溯排查。
