composer install后不会自动清理缓存，其设计本意是复用缓存加速后续操作；缓存默认保留在~/.composer/cache（linux/macos）或%appdata%\composer\cache（windows），含files/、repo/、vcs/三类内容，其中vcs/目录常占300–800mb且clear-cache默认不清理。
composer install 后不会自动清缓存
Composer 没有“安装后自动清理缓存”的机制，composer install 或 composer update 执行完，~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）里的 files/、repo/、vcs/ 全部保留。这不是遗漏，是设计使然——缓存本就为了加速下次操作。
常见误判是：看到磁盘告警 → 跑一遍 composer install → 发现空间没变 → 以为“它该清却没清”。其实问题根本不在缓存是否自动删，而在于你压根没确认过缓存是不是真占地方。
怎么判断缓存值不值得手动清
别凭感觉删。先查路径、再看大小、最后比对真实大户：
- 查当前缓存位置：
composer config --global cache-dir - Linux/macOS 看体积：
du -sh $(composer config --global cache-dir) - Windows 直接在资源管理器地址栏粘贴
%APPDATA%\Composer\Cache→ 右键“属性” - 不到 200 MB？基本不用管；超过 1.5 GB 且半年没碰老项目，才值得动手
- 顺手对比下：
du -sh vendor/—— 中等 Laravel/ThinkPHP 项目，vendor/常占 300–800 MB，远超缓存
真正吃空间的其实是 vcs/ 目录，但 clear-cache 默认不删它
composer clear-cache 会清 repo/、files/、http/，但默认跳过 vcs/。而这个目录才是磁盘杀手：每个 Git 裸仓库（含完整 .git）单个就占 300–800 MB，切分支/换源频繁时极易积攒废弃目录，且几乎不复用。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
安全清理方式（Linux/macOS）：
- 先确认路径：
composer config --global cache-dir - 手动删 vcs：
rm -rf $(composer config --global cache-dir)/vcs/（注意尾部斜杠） - Windows 对应命令：
rd /s /q "%APPDATA%\Composer\Cache\vcs" - 禁用 VCS 缓存（一劳永逸）：
composer config --global cache-vcs false，后续所有包强制走--prefer-dist
删 vcs/ 完全安全，下次需要时自动重建；但别碰 repo/packagist.org/，否则首次 composer update 会明显卡顿。
CI/CD 里加 clear-cache 反而拖慢构建
很多团队在 CI 脚本开头无脑加 composer clear-cache，结果构建时间变长、还掩盖真实问题：
- 清完
repo/→ 下次composer install得重新 HTTP 请求拉取所有packages.json，首屏卡顿是设计行为，不是故障 - 清完
files/→ 所有.zip重下，尤其含大前端资产的包更耗时 - 权限错乱高发：Docker 构建时用 root 跑过 composer，后续非 root 用户执行
clear-cache就报Permission denied - 真正省事的方式是定期
composer self-update—— 新版 Composer（如 2.9.6）对缓存压缩和复用更聪明，比反复清更能稳住磁盘增长节奏
缓存本身不决策装什么版本，也不修复网络或镜像配置问题。清它解决不了 file could not be downloaded 或 Failed to decode JSON，这些八成是代理、源配置或私有镜像 TTL 导致的。
