能，但只是第一步——它只清理 Composer 缓存目录中的 ZIP 包、元数据和安装器缓存，不释放 vendor 或项目文件，且不解决系统临时目录（/tmp 或 %TEMP%）空间不足的根本问题。
直接执行 composer clear-cache 能否解决磁盘满导致的失败？
能，但只是第一步——它只清理 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\cache（Windows）里的 ZIP 包、元数据和安装器缓存，不碰 vendor 或项目文件。如果缓存占了 2GB，清掉后立刻释放，但若磁盘只剩 100MB，而你要装的包解压后要 1.8GB，clear-cache 后依然会卡在 No space left on device。
-
composer clear-cache --dry-run先看缓存实际大小：输出124M值得清；输出4K或提示No cache files to delete就别白跑 - 清完再用
du -sh ~/.composer/cache（Linux/macOS）或dir /s %APPDATA%\Composer\cache（Windows）确认是否真清空 - 若清缓存中途报错（如
Permission denied），说明有composer install进程正锁着某些文件，先ps aux | grep composer杀掉残留进程
为什么 composer install 会突然爆磁盘？临时目录才是真凶
Composer 默认把 ZIP 下载、解压、重命名全放在系统 /tmp（Linux/macOS）或 %TEMP%（Windows）里做，而这个分区往往只有几 GB。比如你 vendor 当前 800MB，但安装一个新包需同时存 ZIP（200MB）+ 解压后文件（600MB）+ 原 vendor 备份（800MB），峰值要 1.6GB 临时空间——/tmp 满了就直接失败。
- 改临时目录：运行
export COMPOSER_CACHE_DIR="/mnt/bigdisk/composer-cache"
，之后所有下载解压都在大分区进行
export TMPDIR="/mnt/bigdisk/tmp"
mkdir -p "$TMPDIR" && chmod 777 "$TMPDIR" - 验证是否生效：
composer config cache-dir和echo $TMPDIR应返回新路径 - 别只改
COMPOSER_CACHE_DIR：不改TMPDIR，解压阶段仍会撞上/tmp空间不足
装包时跳过非必要步骤，压低临时空间峰值
默认 composer install 会启用插件、执行脚本、生成 autoloader、甚至并发下载 4 个包——每一步都可能额外写临时文件。磁盘紧张时，必须砍掉冗余动作。
- 最轻量安装：
php -d memory_limit=-1 composer install --no-plugins --no-scripts --no-autoloader --prefer-dist --no-dev
-
--prefer-dist强制用 ZIP 包而非git clone，省下 .git 目录和 checkout 临时文件 -
--no-dev跳过phpunit、phpcs等开发依赖，通常省 30%–50% 空间 - 如果只是部署，装完再手动跑
composer dump-autoload补 autoloader，比边装边生成更稳
长期维护：别等爆满才动手，建立空间感知习惯
缓存不会自动老化，~/.composer/cache/files/ 里可能躺着三年前下载的旧版 ZIP，而 repo/ 里是过期的 packages.json——它们加起来轻松几 GB，但你根本意识不到。
- 每月一次快速巡检：
du -sh ~/.composer/cache/{files,repo} 2>/dev/null，若files> 1G，立刻composer clear-cache - 全局配置降并发：
composer config -g process-timeout 3600+composer config -g use-include-path false，避免多线程抢资源 - 别删
~/.composer/vendor/bin：那是phpunit、laravel等全局命令所在，删了就执行不了
真正卡住人的从来不是“该不该清缓存”，而是没意识到 composer 的临时操作全程依赖系统 /tmp 分区——换路径、砍参数、定期看，三件事做齐，磁盘告急的报错基本不会再半夜弹出来。
