composer clear-cache仅清除cache-dir下的files/（.zip/.tar包）、repo/（元数据快照）和vcs/（Git裸仓库），不删vendor/、composer.lock或运行时缓存；清后首次安装变慢是因需重下重拉，属正常设计行为。
composer clear-cache 不是万能加速键，它只在缓存损坏、镜像切换后元数据残留、或 checksum 校验失败时才真正起作用；清完首次装包变慢是设计行为，不是命令出错。
composer clear-cache 到底删了哪些路径
它只操作 composer config --global cache-dir 返回的目录下的三个子目录：files/（所有下载的 .zip、.tar 包）、repo/（远程源的元数据快照，如 packages.json）、vcs/（Git 克隆的裸仓库）。不会碰 vendor/、composer.lock、composer.json，也不动 PHP OPcache 或镜像 CDN 缓存。
常见误判是以为清完 vendor/ 会变小——不会。真正占空间的是已安装包的源码，缓存通常几百 MB，但长期不清理可能涨到 2–5 GB。
- Linux/macOS 默认路径：
~/.composer/cache - Windows 默认路径：
%APPDATA%\Composer\Cache - 用
composer config --global cache-dir确认真实路径，别凭感觉删
为什么有时 clear-cache 没反应、卡住或报错
根本原因往往不是命令本身问题，而是环境干扰：
- 权限错乱：之前用
sudo composer install写过缓存，现在普通用户执行被拒绝删除 - 文件被占用：IDE（如 PHPStorm）或杀毒软件正在扫描
~/.composer/cache/files/下的 ZIP，系统锁住不让删 - 缓存路径被覆盖：设置了
COMPOSER_CACHE_DIR环境变量但未生效，clear-cache实际清的是空路径 - 损坏归档残留：断网中断下载后留下的半截
.zip，clear-cache在反复校验 CRC，表现为长时间无输出、磁盘 I/O 几乎为 0
加 --no-interaction 可跳过交互式确认，避免卡在提示；用 lsof +D ~/.composer/cache（macOS/Linux）或 handle.exe -a cache（Windows）查谁在占用文件。
只清某类缓存，而不是全量删
composer clear-cache 是全量操作，但你可以手动进目录精准清理，更省空间也更可控：
- 只删下载过的原始包（节省最多空间）：
rm -rf ~/.composer/cache/files/* - 只清元数据（解决“装不到新版包”类问题）：
rm -rf ~/.composer/cache/repo/* - 只清 Git 克隆缓存（影响 vcs 类仓库拉取）：
rm -rf ~/.composer/cache/vcs/*
手删前务必确认没有 composer install 或 update 进程在后台跑，否则可能触发 Corrupted cache file 报错。删 vcs/ 完全安全，下次需要时自动重建；但别乱动 repo/packagist.org/，这是核心索引，删了会导致首次 composer update 明显变慢。
清完之后装包变慢，是不是命令出错了
不是。这是设计行为：
-
repo/清空 → 下次install得重新 HTTP 请求 packagist.org 或镜像源拉packages.json -
files/清空 → 所有.zip都得重下，尤其含大资产（如 Laravel UI）的包更明显 - 频繁清理又频繁装包，反而拖慢整体节奏；建议控制在每月一次，或仅在磁盘告警（如缓存 >1.5GB 且半年没碰老项目）时执行
真正容易被忽略的是：某些团队把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 composer config --global cache-dir 指向的那个路径，不会遍历所有可能位置。
