能，但仅清理 ~/.composer/cache（linux/macos）或 %appdata%composercache（windows）中的 files/、repo/、installers/，默认跳过占空间最大的 vcs/ 目录。
composer clear-cache 真的能释放空间吗？
能，但只清 ~/.composer/cache（Linux/macOS）或 %APPDATA%ComposerCache（Windows）下的内容，不碰 vendor/、composer.lock 或项目代码。它删的是已下载的 ZIP/TAR 包（files/）、包元数据（repo/）、安装器缓存（installers/），默认**跳过 vcs/ 目录**——而这恰恰是磁盘杀手。
- 先看真实占用：
du -sh ~/.composer/cache（Linux/macOS）或dir /s %APPDATA%ComposerCache（Windows） - 如果输出是
4K或空，composer clear-cache会提示No cache files to delete，白跑 - 常见误判：把
vendor/当缓存——它不属于 Composer 缓存体系，删了项目直接崩 -
clear-cache是安全操作，但释放量常被高估：多数人实际只腾出几百 MB；真占几 GB 的，八成是vcs/里躺着 laravel、symfony 等完整 git 仓库副本
为什么 clear-cache 后还是磁盘满？重点查 vcs/
因为 composer clear-cache 默认不清理 vcs/——Composer 认为 Git 克隆可能复用，但实际部署中几乎从不复用，且每个克隆都带完整 .git 目录，动辄 300–800 MB。
- 精准释放：运行
composer clear-cache后立刻补一句rm -rf ~/.composer/cache/vcs（Linux/macOS）或rd /s /q "%APPDATA%ComposerCachevcs"（Windows） - 别漏掉尾部斜杠：
~/.composer/cache/vcs/和~/.composer/cache/vcs在rm -rf下行为不同，后者更安全 - CI 或小磁盘机器可永久禁用：
composer config --global cache-vcs false，后续 Git 包全走--prefer-dist安装 - 杀毒软件或 ide（如 phpstorm）可能锁住
vcs/文件，导致rm失败，关掉文件索引再试
清理后安装变慢？这是正常代价
缓存不只是 ZIP 包，还包含解析后的 packages.json、哈希校验值、依赖图快照。清完首次 composer update 会重新下载 + 解压 + 重建全部元数据，耗时明显增加。
- 不想完全清空？可只删体积最大的部分：
rm -rf ~/.composer/cache/files（留repo/加速元数据解析） - 长期节省空间：设缓存上限（Composer 2.5+）：
composer config --global cache-max-size "500M" - 迁移缓存路径到大分区：
composer config -g cache-dir /data/composer-cache，避免/home或C:被撑爆 -
--no-cache参数只是跳过读缓存，仍会往系统/tmp写临时文件——而/tmp往往更小，慎用
磁盘满报错 No space left on device，光清缓存不够
真正卡住的常不是缓存本身，而是 composer install/update 过程中在 vendor/ 同级创建的临时解压目录（如 vendor/composer/xxxxx），它需要「原始 ZIP + 解压后体积 + 原子重命名开销」三倍空间。
- 临时缓解：
composer install --no-plugins --no-scripts --no-autoloader --prefer-dist --no-dev，跳过所有中间步骤 - 确保
vendor/所在分区有 ≥ 2× 当前vendor/大小的空闲空间 - 极端情况可挪走
vendor：mv vendor /mnt/bigdisk/myproject-vendor && ln -s /mnt/bigdisk/myproject-vendor vendor - 检查是不是 inodes 耗尽：
df -i，若 Use% 接近 100%，删小文件（vcs/就是典型）比删大文件更有效
最常被忽略的一点：Composer 默认保留每个包最近 3 个版本的 dist 缓存，哪怕你只用最新版。这个行为无法关闭，只能靠定期 clear-cache 手动干预——别等报错才想起它。