运行 composer clear-cache 可直接释放 Composer 缓存空间，它删除 ZIP 包、dist 包和安装器缓存，不影响已安装项目；需先用 du -sh 或 dir /s 查看缓存大小，权限错误时应终止锁定进程。
清理 Composer 缓存目录释放空间
Composer 本身不自动清理旧包缓存，~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\cache（Windows）长期积累可能占数 GB 空间。运行 composer clear-cache 是最直接的释放方式，它会删除所有已下载的 ZIP 包、已解压的 dist 包和已生成的安装器缓存。
- 执行前可先用
du -sh ~/.composer/cache（Linux/macOS）或dir /s %APPDATA%\Composer\cache（Windows）确认缓存大小 -
clear-cache不影响已安装的项目依赖，只清本地缓存 - 若提示权限错误，说明某些缓存文件被其他进程锁定（如正在运行的
composer install），需先终止相关进程
跳过 vendor 目录重建避免临时磁盘暴增
当 composer update 或 composer install 失败并报 No space left on device，常见原因是 Composer 在 vendor/ 同级目录创建临时解压目录（如 vendor/composer/xxxxx），再原子替换。如果磁盘剩余空间小于待安装包解压后体积，就会失败。
- 改用
composer install --no-plugins --no-scripts可减少中间步骤和临时文件生成 - 确保
vendor/所在分区有至少 2× 当前vendor/大小的空闲空间（解压 + 原始 ZIP + 重命名开销） - 若磁盘确实紧张，可临时将
vendor/移到另一分区，用符号链接回原位：mv vendor /mnt/bigdisk/myproject-vendor
ln -s /mnt/bigdisk/myproject-vendor vendor
限制 Composer 下载并发与压缩级别降低 I/O 压力
默认 Composer 并发下载 4 个包，并使用 zlib 最高压缩比解压 ZIP，这对低内存或小磁盘设备很不友好。可通过配置降低资源峰值占用：
- 设置并发数为 1：
composer config -g process-timeout 3600 && composer config -g use-include-path false && composer config -g github-protocols ["https"] && composer config -g cache-dir "/tmp/composer-cache"（再配合COMPOSER_MEMORY_LIMIT=-1防 OOM） - 强制使用更轻量的解压方式：在
composer.json中添加"config": {并确保不启用
"fxp-asset": {
"installer-paths": {"npm-asset-library": "assets/npm"}
},
"discard-changes": true,
"preferred-install": "dist",
"github-oauth": {}
}fxp/composer-asset-plugin这类高内存插件 - 禁用 ZIP 解压缓存（不推荐长期使用）：
composer config -g cache-files-ttl 0，让每次下载都跳过本地 ZIP 复用，但会增加网络请求
检查系统级磁盘占用而非仅 Composer 问题
No space left on device 不一定源于 Composer 自身——可能是 /tmp 分区满（Composer 默认用系统 tmp）、Docker overlay2 占满、journal 日志撑爆 /var/log，或 inode 耗尽（df -i 查看）。
- 运行
df -h和df -i确认是空间还是 inode 不足 - 清理
/tmp：sudo find /tmp -type f -mtime +7 -delete（注意别误删正在使用的临时文件） - Docker 用户重点检查：
docker system df -v，必要时docker system prune -a --volumes - systemd 日志：
journalctl --disk-usage→journalctl --vacuum-size=200M
df -h && df -i，比盲目 composer update 重试有效得多。 
