composer clear-cache 仅清理缓存目录（如~/.composer/cache），不触碰vendor/等核心文件；它对坏包、版本卡旧、元数据残留有效，但非万能，超1.5GB且长期未用项目才需清理。
composer clear-cache 能释放磁盘空间，但多数时候它不是省空间的主力；真正占地方的是 vendor/，不是缓存。它只对“坏包”“版本卡旧”“元数据残留”有效，不是万能重启键。
怎么确认缓存真占空间？别猜，直接查路径和大小
先看 Composer 自己认的缓存在哪：composer config --global cache-dir。Linux/macOS 下通常是 ~/.composer/cache，Windows 是 %APPDATA%\Composer\Cache。
再看它到底占多少：
- Linux/macOS：
du -sh $(composer config --global cache-dir) - Windows：打开资源管理器，导航到上面查出的路径，右键 → 属性
如果不到 200MB，基本不用清；超过 1.5GB 且你半年没碰某些老项目，才值得动手。有些公司把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清配置指向的那个路径，不会遍历所有可能位置。
composer clear-cache 到底删什么、不删什么
它删的是 ~/.composer/cache/（或 Windows 对应路径）下的全部内容，包括：
-
files/：所有.zip、.tar包 -
repo/：packages.json快照等元数据 -
vcs/：git 克隆缓存（安全，下次需要自动重建） -
http/：HTTP 响应缓存（Composer 8+ 新增）
它**不碰**：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
vendor/目录（哪怕你删了它，clear-cache也不会动） -
composer.lock和composer.json -
~/.composer/config.json或auth.json（镜像源、GitHub token 都保留）
执行后输出类似 Cleared cache for all packages (12.4 MiB)，没输出 ≠ 失败，只是没东西可清。
清完还装错版？那大概率不是缓存的问题
常见误判：
- 运行
composer install还是装旧版 → 不是缓存没清干净，而是composer.lock锁死了版本 - 切了国内镜像（如阿里云）但
require还走原地址 → 缓存里存了旧源元数据，这时清才有用 - 私有包改了 tag 却一直装旧版 → 清缓存才能让 Composer 重新查远程，否则它直接复用本地解压结果
但以下情况清缓存完全无效：
-
Could not find package xxx：多半是拼写错误或源没配对 - PHP 版本不匹配、
composer.json语法错误、xdebug 启用中 -
Failed to extract报 zlib error：可能是磁盘写入中断导致 zip 损坏，此时清缓存有用；但若反复出现，优先升级 Composer 到 2.5+
想精准清理？没有内置命令，只能手动筛
composer clear-cache 是全量清，Composer 不提供按包名、时间、大小筛选的选项。“精准”只能靠你自己进目录认路：
- 清老
.zip包（90 天前）：find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 清废弃 git 缓存：
rm -rf ~/.composer/cache/vcs/*（安全） - 别乱动
repo/packagist.org/：这是核心索引，删了会导致首次update明显变慢
手删前确保 composer 没在后台运行，否则可能引发 Corrupted cache file 报错。真正省事的方式其实是定期跑 composer self-update——新版对缓存压缩和复用更聪明，比反复清更能稳住磁盘增长节奏。
