直接运行composer clear-cache仅清除全局缓存目录（Linux/macOS为~/.composer/cache，Windows为%APPDATA%\Composer\Cache）中的files/、repo/、vcs/子目录，不删除vendor/、composer.lock或项目文件；清缓存前须用composer config --global cache-dir确认路径并检查大小，避免误操作。
直接运行 composer clear-cache 就能清掉本地缓存，但它只动 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）里的内容，绝不会碰你的 vendor/、composer.lock 或项目代码——这点不确认清楚，后面所有操作都可能白忙。
怎么确认缓存真占地方、该不该清
很多人一看到磁盘告警就跑 composer clear-cache，结果发现空间没少多少。缓存不是万能垃圾桶，得先看它是不是真元凶：
- 查路径：
composer config --global cache-dir，输出就是 Composer 实际认的缓存根目录 - 看大小：Linux/macOS 运行
du -sh $(composer config --global cache-dir)；Windows 直接打开资源管理器，粘贴%APPDATA%\Composer\Cache进地址栏，右键 → “属性” - 不到 200MB 基本不用管；超过 1.5GB 且你半年没碰某些老项目，才值得动手
- 有些公司把缓存挂到 NFS 或自建镜像目录，
clear-cache默认只清配置里那个路径，不会遍历所有可能位置
为什么清完还是装旧包、还是报错
缓存只是加速层，不是决策源头。清了它，不代表依赖会升级，也不代表网络问题能解决：
-
composer install装什么，由composer.lock和repositories配置决定；清缓存只是让它重新下载远程元数据，不一定触发版本变化 - 遇到
file could not be downloaded或Failed to decode JSON，大概率是网络、源配置或代理问题，不是缓存脏了 - 刚切了国内镜像（比如阿里云），但还报 404？先确认
composer config repo.packagist false已生效，否则缓存清理白搭 - 私有源响应头带
X-Composer-Cache-TTL（如腾讯云 TKE 镜像），本地清了也没用，得等镜像源自己过期，或临时切回官方源验证
想精准删部分缓存？只能手动进目录筛
composer clear-cache 是全量清，没有按包名、按时间、按大小筛选的选项。所谓“精准”，只能靠你自己进目录判断：
- 删老 zip 包（90 天前）：
find ~/.composer/cache/files -name "*.zip" -mtime +90 -delete - 清废弃 Git 缓存（安全，下次需要自动重建）：
rm -rf ~/.composer/cache/vcs/* - 别乱动
~/.composer/cache/repo/下的packagist.org/目录——这是核心索引，删了会导致首次composer update明显变慢 - 手删前务必确认
composer进程已退出，否则可能删到一半被写入，后续报Corrupted cache file
真正容易被忽略的是：某些团队把缓存挂到 NFS 或自建镜像目录，clear-cache 默认只清 composer config --global cache-dir 指向的那个路径，不会遍历所有可能位置；还有 CI/CD 中混用用户（比如 Docker 构建时用 root 跑过 composer），后续非 root 用户执行 clear-cache 就会失败——权限和路径，比命令本身更常出问题。
