执行 composer clear-cache 可安全释放缓存空间，但需先用 composer config --global cache-dir 确认路径，再用 du -sh（Linux/macOS）或资源管理器（Windows）查看实际体积，超1.5GB且长期未用才建议清理。
直接执行 composer clear-cache 就能安全释放空间，但别一上来就跑——先确认它是不是真占地方、路径对不对、有没有被镜像改过位置。
怎么查缓存占了多大、在哪儿
缓存路径可能被公司镜像或自定义配置改过，composer config --global cache-dir 才是唯一可信来源。别猜 ~/.composer/cache 一定对。
- Linux/macOS：运行
du -sh $(composer config --global cache-dir)看实际体积 - Windows：打开资源管理器，粘贴
%APPDATA%\Composer\Cache进地址栏，右键“属性” - 如果不到 200MB，基本可以排除它是磁盘告警主因；超过 1.5GB 且你半年没碰某些老项目，才值得动手
为什么 composer clear-cache 比手动删目录更安全
手动删 ~/.composer/cache 目录看似快，但容易触发锁冲突或损坏缓存结构，尤其在 WSL 或 Windows 上。
-
composer clear-cache会先暂停写入锁，再逐个清空repo/、files/、vcs/子目录，最后重置cache.json - 它不碰
auth.json、config.json，也不动项目里的vendor/或composer.lock - 执行后输出类似
Cleared cache for all packages (842 MiB)，括号里是真实释放量，不是估算
清完为啥装包变慢？这不是 bug，是设计
缓存清空后首次 composer install 或 composer update 必然变慢，因为要重新下载所有 .zip 包和元数据。
-
repo/缺失 → 每次都要 HTTP 请求镜像源拉packages.json -
files/缺失 → 所有 dist 包重下，含大资产的包（如 Laravel UI）最明显 - 国内用户建议提前配好阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
想精准清理旧包而不是全删？只能手动筛
Composer 没有 --only-unused 或 --before 2025 这类参数。所谓“精准”，靠的是你进目录比对 composer.lock。
- 进
~/.composer/cache/files/，子目录名通常是vendor-name/version.zip格式 - 打开项目
composer.lock，搜"name": "monolog/monolog"，看"version"字段值 - 只删那些不在任何项目
composer.lock中出现的 zip 文件，别整包目录全删 -
vcs/可以放心全清：rm -rf ~/.composer/cache/vcs/*，下次需要时自动重建，很安全
真正容易被忽略的是 inodes 耗尽——尤其 WSL 或 macOS APFS 下，df -h 显示还有空间，却报 No space left on device。这时候跑 df -i，如果 Use% 接近 100%，就得清小文件，而 Composer 的 vcs/ 目录正是重灾区。
