答案是/tmp或系统临时目录inode或空间耗尽而非磁盘块不足；需先用df -h /tmp（Linux/macOS）或dir %TEMP%（Windows）确认占用率，再sudo rm -rf /tmp/composer_*等残留文件，因composer clear-cache不清理/tmp。
Composer install 报 No space left on device 但磁盘没满
这基本是 /tmp 或系统临时目录被占满，而非项目所在磁盘空间不足。Composer 在解压 zip、生成 lock 文件、运行 SAT 求解器时会大量使用 /tmp（Linux/macOS）或 %TEMP%（Windows），尤其在 CI/CD 环境或频繁执行 composer update 后极易堆积残留文件。
- 先确认真实瓶颈：运行
df -h /tmp（Linux/macOS）或dir %TEMP%（Windows），看是否已 100% 占用 - 别只盯着
~/.composer/cache——它不是元凶，/tmp才是高频爆仓点 - 常见残留物：
composer_*.zip、composer_dist_*、未清理的phar解压目录，它们往往权限为 root 或属主异常，rm -rf前得先sudo - 临时释放：Linux/macOS 下可直接清空
sudo rm -rf /tmp/composer_*；Windows 下用del /q "%TEMP%\composer_*"（需管理员权限）
为什么 composer clear-cache 不解决这个问题
composer clear-cache 只清理 ~/.composer/cache 下的内容，对系统 /tmp 目录完全无影响。很多用户误以为“缓存清了就没事”，结果重试仍报 No space left on device。
-
clear-cache不碰/tmp、不删phar临时解压目录、不处理失败安装中途残留的 unpacked 文件夹 - 某些 Composer 插件（如
hirak/prestissimo）会在/tmp创建持久化 socket 文件，长期不重启进程就会越积越多 - CI 环境中若未配置
cleanup步骤，每次 job 都往/tmp写新内容，几轮下来就撑爆
如何让 Composer 少用 /tmp
根本解法不是定期清空，而是把临时操作导向可控路径。Composer 本身不提供全局 tmp 路径配置，但可通过环境变量和 PHP 设置干预。
- 设置
COMPOSER_CACHE_DIR仅影响缓存，不影响临时解压——真正起作用的是sys_get_temp_dir()的返回值 - 覆盖 PHP 临时目录：启动时加
-d sys_temp_dir=/path/to/writable/tmp，例如php -d sys_temp_dir=/home/user/tmp composer install - Linux 下可临时挂载内存盘：
mkdir -p /home/user/tmp && mount -t tmpfs -o size=512M tmpfs /home/user/tmp，再配合上一条使用 - Windows 用户注意：
%TEMP%若指向系统盘且空间紧张，可在系统属性 → 高级 → 环境变量中改指向另一个盘符下的干净目录
容易被忽略的权限陷阱
/tmp 目录本身权限通常是 drwxrwxrwt（sticky bit），但子目录可能被 root 创建后普通用户无法删除——这会导致看似有空间，实则写入失败。
- 运行
ls -ld /tmp确认权限含t，否则其他用户无法删别人建的目录 - 检查残留文件属主：
ls -la /tmp | grep composer，若看到root创建的composer_*，普通用户rm会 Permission denied - 不要盲目
chmod 777 /tmp——破坏 sticky bit 会引发更严重的安全与协作问题 - 稳妥做法：用
sudo chown -R $USER:$USER /tmp/composer_*再清理，或直接sudo rm -rf /tmp/composer_*
df、ls -la /tmp 和 -vvv 日志中 “failed to open stream” 或 “Cannot create temp file” 类错误才能准确定位。 
