直接运行composer clear-cache即可安全清除缓存，它仅清理~/.composer/cache或%APPDATA%\Composer\Cache下的files/、repo/、vcs/三个子目录，不触碰vendor/、composer.lock及项目文件。
直接运行 composer clear-cache 就行，它只清缓存目录下的 files/、repo/、vcs/ 三个子目录，不删 vendor/、composer.lock 或任何项目文件——这是最安全、也最常被误操作的边界。
为什么 composer clear-cache 有时没反应或报错
常见现象是执行后提示 Cache directory does not exist，或反复运行缓存大小不变。根本不是命令失效，而是路径或权限卡住了：
- 之前用
sudo composer install写过缓存，现在普通用户执行clear-cache会被拒绝删除（Linux/macOS 常见） - 设置了
COMPOSER_CACHE_DIR环境变量但未生效，clear-cache实际清的是空路径 - 杀毒软件或 PHPStorm 正在扫描
~/.composer/cache/files/下的 ZIP，系统锁住不让删 - Docker 构建时用 root 跑过
composer，后续非 root 用户执行就失败
怎么确认缓存路径和真实占用大小
别凭感觉删。先查 Composer 当前认的缓存目录在哪，再看它到底占了多少空间：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config --global cache-dir，输出就是真实路径（Linux/macOS 通常是~/.composer/cache，Windows 是%APPDATA%\Composer\Cache） - Linux/macOS 下接着跑：
du -sh $(composer config --global cache-dir)，一眼看出体积 - Windows 用户打开资源管理器，粘贴
%APPDATA%\Composer\Cache进地址栏，右键 → “属性” 看大小 - 如果不到 200MB，大概率不是磁盘告警主因；超过 1.5GB 且你半年没碰某些老项目，才值得动手
想只清某类缓存，而不是全量删
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报错
清完之后装包变慢，是不是命令出错了
不是。这是设计行为，不是故障：
-
repo/清空 → 下次install得重新 HTTP 请求 packagist.org 或镜像源拉packages.json，首次明显卡顿 -
files/缺失 → 所有.zip都得重下，尤其含大资产（如 Laravel UI、前端模板）的包更明显 - 频繁清理又频繁装包，不如每月一次，或仅在磁盘告警时执行
- 真正省事的方式其实是定期跑
composer self-update—— 新版 Composer 对缓存压缩和复用更聪明，比反复清缓存更能稳住磁盘增长节奏
最容易被忽略的一点：缓存目录如果是软链接到 NAS 或挂载盘，某些文件系统不支持原子删除，得先 cp -r 到本地再删原链接；另外，--dry-run 参数虽不常用，但执行前加一句 composer clear-cache --dry-run 能帮你确认路径是否真在预期位置，尤其在 CI/CD 或共享环境里很实用。
